From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 31B352615D for ; Wed, 13 Mar 2024 14:23:07 +0100 (CET) Received: (qmail 28279 invoked by uid 550); 13 Mar 2024 13:18:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20202 invoked from network); 13 Mar 2024 01:12:57 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wosf4A4vfrEx+xAlEr4Zn8k91hkRAtrgm2Xp28mGRSPX18W4mdKgL7mMpvOoAjEBq4DkNUXDpO7SToClN2lbhDogJNAhOkJJW0zWOpUg+nOpt6Yna7guecNYVcBSTycsp9dKulQ/iJGISUymwWab5UvrxfWD2rvHHLe8A38Al6D5NfiGa8/wuQrELR8LtazF3s/2xLqVA+8e0UPpLjWOZGN67OIftdHd6SLhLNgAQy952HQDaU41J2CxvrX5aWuXHjpSbHVXLLBXRPRywTABqV4SEzHT0wgxc3i8RuGDqwqxrJZve6JgeaXPaFcz+0mMqT9nbvjJDIM1E/kwEweR2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=guuglfi7/rs7UIBJRkN55qBKaJ2ETzKc2/9MUVBxSIw=; b=Jx6fNnL36uUTzG6EoTABOoEqKVenkS5avA12gu0pzM4tuBh9RAuXclL4NI+s5njqcSF+J/zrdwSpmfm8I6K3e6Iaj6plZkiHbdD+DdFwz+wXkczp++sGwzOHf+fAqBpPAAlLAVqTGT4pHR/+/gkxzn9ocbyhucFjbTC3pZfbajNFqTbfiPDX6j1FrDz5zb2lmqV6LZFYs5hVUUfz8uOeRvLvJXnj8k7dC7FtG4zVtkaR+Q6DPSPFo7Xnjl6mh6gzoareYEIdt6+khDBBWeHWOr1EYtsiG9cXDiRJFgpAAXzZOvNnmxyK5rrT153UjGn95Xc8kgcK+fV/lzebGx4bCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=guuglfi7/rs7UIBJRkN55qBKaJ2ETzKc2/9MUVBxSIw=; b=NFUdrqDU0BwolgtBHI59UEDzYLOsvjwhYtCpoTBu/Vfxkb5EL2OH4nI1ogYXVySkChDmBnYoI1NFwGh2Pcuwn6daERcbxSKhtq29C8uJ/zD3KI1NvqkQGE4gE+LLR02bDLBtA7J0VLbA4bJddPCdvDZM+ZbJ4zGoJtw1bsvRkyg= From: Colen Garoutte-Carson To: "musl@lists.openwall.com" Thread-Topic: incomplete GDB backtrace stacks with MUSL cross toolchain Thread-Index: Adp04vZpc+hHbiqaQYahMqrnlaRyCg== Date: Wed, 13 Mar 2024 01:16:47 +0000 Deferred-Delivery: Wed, 13 Mar 2024 01:15:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4d858193-1902-4e05-a708-13369040c716;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2024-03-13T00:59:48Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR21MB1612:EE_|DM6PR21MB1484:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8IIb3XHWJWS6r64lm0Mn0V8vT0rUrf6ug2pdolKfF9A3BWR2WFfydXGrZo0E6HifV4mdHNAukDrdJb148iVKBv3DiWWZjpQcs9b/Egcr98P9vCMbJj0hYMDgLnwTO2Le9dW72+6W/U/MjGWVUouSgLuSiytWi1faecFmUpShhaT9073P+N7muboaeCReKt96B2WfOPQOfHgjnU77nC8JbcNFgZxJHg2itiLWIhWeG2Hp4mU+c3+eLmCSSOulqHMqkNppqB5DqSSyP2kdcayEjk8fIwi/9cnifRXBQDgjhA2O7n7JPLtfYTIW0pJIypzZjJr6wI3T/JZ0tIw+fkMdloOh8TIAGSeHpbe0+DBfnqBDiqvcmTinME2DVIi7Nx/qhTVVKOwe2DaRBVx91JFT2SuNk+J3JdSP9KYcM6MAzDym5uv8uNX6XzhH7rYUfQO/SaYWRY2zwVdpBmeB14cQnaKHuvNZSnFgCqHRD+MLcXc+taeTz6EjoXwdCbYc/D559jmZv6ddcaDUMLj5ZcTk3Pdw3K7TkRBr1o4zLvEVlogWf2EV7KZXJToFhST2PmvUbDpXp3xk0ge1lCyklDjcaZd8zNyOsCz47UsBGtdaQmTWqHIOyycYO7KBGQUVRtM9 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR21MB1612.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BOw3yKu6i5GxvhxLy/qVjLHSp1Q2rg+ESehyTrqTQ0hSatE1Wg5L2Yk9XPvu?= =?us-ascii?Q?meeqekxt4WsykjDqkYaJUM1Pmfbf5psYeRJ1gnMPINauUIpCFe+nYvB1Etlg?= =?us-ascii?Q?ItLbwoS1OjQ/vie5Ecipvm+z8hTiUSkg1csTKxkKV6YQCyiHqzVa/qnYKDCO?= =?us-ascii?Q?cUMPPtDY0mh8f0FkSVXMVA/0YxkUGV+vOk+/rbAFJ/uN+5v24B0mPrLhxUxe?= =?us-ascii?Q?L4Xb9txHWSN4IhsfbuuWpoZJQdsHmAlmLCFklHn7/jb9ouvzU4c/Qc8OHApJ?= =?us-ascii?Q?gj0a7IItfbPPbcGZxrMPYk0mtS09FisemY8MvTfYQZnOUMn9IWsU//uXytHR?= =?us-ascii?Q?SX70I2UYzJpRjLM/iXuXaIrFltc+7xdha+J0QHzgWm52NFiJ4xOKDXciA2zv?= =?us-ascii?Q?5G0f7K16/znUckAzHX3iF7KjRQuoprUubudM+bBpak99olqIFZpLlTR+q+U+?= =?us-ascii?Q?MCVnDclHdwzvYqZ+0qIJcAcFgW4x0uMVkD5XFOstECnoOHiYPAKsXWrTOMB9?= =?us-ascii?Q?6/l87/1mz/ptRczIur45TBBR55icmD4fu9m0fD6sTdzqmFQizEln9x92uzsS?= =?us-ascii?Q?WAMMx35XrtC/ZYoQ6QsqalJYajCgsex4YFa5RKV1c+fX9CX3kI+W17vGJddb?= =?us-ascii?Q?Cl4Tfi2BlIK0/j/ztS26k//HM8B6P9NtINE51C2qzo99aJxFtn2AlnDqQq/6?= =?us-ascii?Q?oYBZxw39/7ktF7jUFZCQhgZpYjoVCwsPIK4jUtgiAQOSc1fVRsuGVZ8lMdEZ?= =?us-ascii?Q?00XNx+2C/EeBamrrgec1+ORf85wK2do6wnqER1IpkWET1n2I/BDo2BkIiRMv?= =?us-ascii?Q?mLwopePXvsNrrlYh6PxbAfZM40pIiIa23gyoKiqbxepGbGHLhTywU9IkrMpd?= =?us-ascii?Q?Z6VHCxM/LaxS8fKuwPdEgOsNRRigE5U1LHkm3HtSeIRH0czAcFi2J/o5bWkC?= =?us-ascii?Q?FnOzXfW76pkZYTkqc8HURxBCaRWcdOF0XoRYbzpwsQurMqafEfdaNqlryD6c?= =?us-ascii?Q?d391XYZCJ5Pc5mK8gOCAuyR20vTqqlUf3Nz0D2EJhYNMFxKBvZLZAXiJIFAY?= =?us-ascii?Q?rnIJEYIAqEabiHlinFcr37YhfDQyv05UJzs8EiEb/r+Pxxv5RsYr33Sjr3q4?= =?us-ascii?Q?qYXJRvd3rwgzzJig7asVgCbUJCVrVx11B03oy0/w85cVX58+fm83yqK/6N1t?= =?us-ascii?Q?L8BEoHaS/twrMIOamLU80Q+3KnNwDWotae1UhSi85ls35hB/wvnezglwE35D?= =?us-ascii?Q?4i57ifArkQ1Je6D1bLou0gXu8O1P+ieYmnVqBn9S+Gry3AmrK3cfmSamoGzj?= =?us-ascii?Q?15Oevra6HLQyn2+UPFO7X+O0a1kUXhq0276jd5NEu6wo/iegzxL8DPbzaUFb?= =?us-ascii?Q?qekbLOqfLAWHz9wTe54k0x4rTe/D+/E9lwXW1iuMSfwiZWwFk49yYyTiU8rp?= =?us-ascii?Q?0rZUH1SOIzTFDOGmu1eiixGJSFd/tZVcRshnB09aZbhH5aQPgSdhao5SFqns?= =?us-ascii?Q?jmD5oZZaFnpZmox/oWHsP91/VJY0ZCQoHhTWoQt4/ungkzl/bZ4jX0cj9G2f?= =?us-ascii?Q?AqcTEX2D0H5vLTbPg02P5VmtNjYXv7hTgDmGP5m/?= Content-Type: multipart/alternative; boundary="_000_DM6PR21MB16125BA8BB0FF55562BFD7AFCD2A2DM6PR21MB1612namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR21MB1612.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f91341c0-a4e5-46b3-c32c-08dc42fb44eb X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2024 01:16:53.9675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: erb+Rv7aOCewF2ojI8BtfDxhogMcDSHpLTVNY3SEHd2Jq+MbqexZQPF8H93R/HV0sm/a9rmEKcuAQUzZiXvjmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR21MB1484 Subject: [musl] incomplete GDB backtrace stacks with MUSL cross toolchain --_000_DM6PR21MB16125BA8BB0FF55562BFD7AFCD2A2DM6PR21MB1612namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We're using MUSL cross-compilation toolchains to build ful= ly statically linked binaries, targeting x86_64, aarch64, and armel. (Which= allows us to work around some issues with glibc incompatibilities) If we connect GDB to our process and get a backtrace, we g= et very little. i.e.: __syscall_cp_c (Unknown Source:0) __timedwait_cp (Unknown Source:0) [Unknown/Just-In-Time compiled code] (Unknown Source:0) Or: __stdio_read (Unknown Source:0) [Unknown/Just-In-Time compiled code] (Unknown Source:0) We'd really like to get the rest of these stacks to invest= igate issues such as deadlocks, for example (among several other reasons, s= uch as our own crash reporting handler). I found related info on StackOverflow, such as: debugging = - Why does gdb backtrace show only one frame when catching syscall? - Stack= Overflow And: c - Stack frame NULL in backtrace log - Stack Overflo= w My hypothesis is that we're calling into code that does no= t provide the stack unwind descriptors needed by GDB. The first of the abo= ve links refers specifically to MUSL and patching it (but for MIPS). I've tried building a fresh MUSL (1.2.4) GCC (13.2.0) tool= chain, and the issue persists with a binary built with it. Can someone explain what we're running into here, and whet= her there is a potential solution (even if we may have to contribute it our= selves)? Thanks!, * Colen --_000_DM6PR21MB16125BA8BB0FF55562BFD7AFCD2A2DM6PR21MB1612namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

        &nbs= p;        We’re using MUSL cross-c= ompilation toolchains to build fully statically linked binaries, targeting = x86_64, aarch64, and armel. (Which allows us to work around some issues wit= h glibc incompatibilities)

 

        &nbs= p;        If we connect GDB to our proce= ss and get a backtrace, we get very little.  i.e.:

 

__syscall_cp_c (Unknown = Source:0)

__timedwait_cp (Unknown = Source:0)

[Unknown/Just-In-Time co= mpiled code] (Unknown Source:0)

 

Or:

 

__stdio_read (Unknown So= urce:0)

[Unknown/Just-In-Time co= mpiled code] (Unknown Source:0)

 

        &nbs= p;        We’d really like to get = the rest of these stacks to investigate issues such as deadlocks, for examp= le (among several other reasons, such as our own crash reporting handler).<= o:p>

 

        &nbs= p;        I found related info on StackO= verflow, such as: debugging - Why does gdb backtrace show only one frame when catching syscal= l? - Stack Overflow

        &nbs= p;        And: c - Stack frame NULL in backtrace log - Stack Overflow

 

        &nbs= p;        My hypothesis is that we’= ;re calling into code that does not provide the stack unwind descriptors ne= eded by GDB.  The first of the above links refers specifically to MUSL= and patching it (but for MIPS).

 

        &nbs= p;        I’ve tried building a fr= esh MUSL (1.2.4) GCC (13.2.0) toolchain, and the issue persists with a bina= ry built with it.

 

        &nbs= p;        Can someone explain what we= 217;re running into here, and whether there is a potential solution (even i= f we may have to contribute it ourselves)?

 

Thanks!,

  • Colen

 

--_000_DM6PR21MB16125BA8BB0FF55562BFD7AFCD2A2DM6PR21MB1612namp_--