From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5301 invoked from network); 10 Feb 2022 21:29:50 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Feb 2022 21:29:50 -0000 Received: (qmail 9520 invoked by uid 550); 10 Feb 2022 21:29:47 -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 24464 invoked from network); 10 Feb 2022 18:05:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hU8Swm/xfA1xN4SxLugs/H6l1uaMIsobBPOzFci3hFI=; b=WEU9QTo4qMXJkJI5Xucpc00CVrF8SJ5ltt/j2cZ4ksSeQPulXb+mQ5S241DXYXxsAR 3/tEBATKvZADGvsLBoTuNezzy+lLxJZ1T3geX3L8d3okjC571SvKRJt+mXizcWKlpbU6 HLXBTh4pf0w5QYu+MHoFexFuNIaCMvXP1W6ICmvuA8YRKDIx7Jq+K0LcEzmVd3arpybP BtzvV1IYGM4ny+PI+zDyR7Da4r7I0CzB8vsIb3CnhhoEBL33Y6XkM+cr8NKNjzbPz1qu fHOHrSvaWJFgU8tF2D8XODlkxVQBnecxDcCgnYyU1veu4/NSnR0F9w+iP6QGIwNuO8f+ pPfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hU8Swm/xfA1xN4SxLugs/H6l1uaMIsobBPOzFci3hFI=; b=sFwRD2N+FiKY+tLjD3jbnevch6sjYrW5wrHA4TY6ti8vwPSWdFeQIy9+N1HMZsInG4 iWkm4Y6U4boQXUikYxqLVSsmGbJWCT09RwEf+iIwhFkSQtPjru+5Iq/Fe/pOOMKXYO8h T0vG9m+sT9tQZieVYGy53iQRrdHblMN5xUvFducJfBdLK1d10e6QHGxxQTiBDmqD30H8 EMdlQ9D1IUk6NXilzKnE2IWJoB5QlZFjPQAAjKRZvHfLI0zWQ7YQTHkiReTAWW7hGTOb dotxl/oiSF1LVnrXTJgHXheBDz2Ess5Ef5I5dTsG3Z9tXY1SEHOL3zMnW/l0VXuVoIpg tA+A== X-Gm-Message-State: AOAM532AVzalIFvPh8Vjgra1na4CPzmzdQ3Z6zlfxutZD/C4kJiiYXcQ NOYU8ucHw3US5nx+DR2VX3Cw9V/+gVZ60nBX02c= X-Google-Smtp-Source: ABdhPJyhDs3gUIlOO+hZ9W0oxRT1Z3m0fzmfDEIdFrld7HmC/vh8fUQAgfquNk1jfu5SZJcbqBT5y+kmb7FNq5c3Ds0= X-Received: by 2002:a05:6602:2b8b:: with SMTP id r11mr4395235iov.165.1644516327883; Thu, 10 Feb 2022 10:05:27 -0800 (PST) MIME-Version: 1.0 References: <20220209183326.GB7074@brightrain.aerifal.cx> <87h797zs6a.fsf@oldenburg.str.redhat.com> <20220209223155.GD7074@brightrain.aerifal.cx> <87a6ezx8wc.fsf@oldenburg.str.redhat.com> In-Reply-To: <87a6ezx8wc.fsf@oldenburg.str.redhat.com> From: Yehuda Yitchak Date: Thu, 10 Feb 2022 20:05:15 +0200 Message-ID: To: Florian Weimer Cc: Rich Felker , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000008d085705d7adcbec" Subject: Re: [musl] Accessing Thread-Local-Storage in GDB --0000000000008d085705d7adcbec Content-Type: text/plain; charset="UTF-8" I forgot to mention I work on arm64 I guess there isn't much I can do at the moment, right ? On Thu, Feb 10, 2022, 13:23 Florian Weimer wrote: > * Rich Felker: > > > Indeed, I was just offering a quick workaround that might help, not > > suggesting gdb should do that. __tls_get_addr can be used for > > non-dynamic symbols with information already available to the > > debugger. For core files you could probably simulate execution and > > abort if anything is reached that would need to change process state > > (lazy allocation) although that doesn't happen with musl anyway. But I > > wonder if the core file even records the x86 segment information > > needed to preserve thread pointer and simulate the %fs/%gs based > > loads on x86[_64]..? > > The register is available as $fs_base on x86-64: > > (gdb) print (void *)$fs_base > $1 = (void *) 0x7f2d12981740 > (gdb) print *(void **)$fs_base > $2 = (void *) 0x7f2d12981740 > > It probably does not work on i386 (even as $gs_base). I do not think it > depends on FSGSBASE support in the kernel, but maybe I'm mistaken. I > think I looked at this three years ago and couldn't make it work. > > Thanks, > Florian > > --0000000000008d085705d7adcbec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I forgot to mention I work on arm64
I gu= ess there isn't much I can do at the moment, right ?

On Thu, Feb 1= 0, 2022, 13:23 Florian Weimer <fwe= imer@redhat.com> wrote:
* Ri= ch Felker:

> Indeed, I was just offering a quick workaround that might help, not > suggesting gdb should do that. __tls_get_addr can be used for
> non-dynamic symbols with information already available to the
> debugger. For core files you could probably simulate execution and
> abort if anything is reached that would need to change process state > (lazy allocation) although that doesn't happen with musl anyway. B= ut I
> wonder if the core file even records the x86 segment information
> needed to preserve thread pointer and simulate the %fs/%gs based
> loads on x86[_64]..?

The register is available as $fs_base on x86-64:

(gdb) print (void *)$fs_base
$1 =3D (void *) 0x7f2d12981740
(gdb) print *(void **)$fs_base
$2 =3D (void *) 0x7f2d12981740

It probably does not work on i386 (even as $gs_base).=C2=A0 I do not think = it
depends on FSGSBASE support in the kernel, but maybe I'm mistaken.=C2= =A0 I
think I looked at this three years ago and couldn't make it work.

Thanks,
Florian

--0000000000008d085705d7adcbec--