public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Avi Kivity <avi@scylladb.com>,  gdb@sourceware.org
Subject: Re: debuginfod vs libthread_db.so
Date: Wed, 30 Nov 2022 19:46:14 +0100	[thread overview]
Message-ID: <87bkoo46x5.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <6cf1a5ef8636a1603181f0b177909a1e7869ece9.camel@klomp.org> (Mark Wielaard's message of "Thu, 24 Nov 2022 13:24:00 +0100")

* Mark Wielaard:

> Hi Avi,
>
> On Thu, 2022-11-24 at 14:02 +0200, Avi Kivity via Gdb wrote:
>> (tangent: is it possible to express libthread_db.so code as DWARF
>> expressions? if so it will be possible to get rid of libthread_db.so,
>> by having libc encode accessors to thread information as some DWARF
>> expressions, and teaching gdb to use those expressions instead of
>> calling libthread_db.so)
>
> There used to be an effort to define a kind of extended DWARF
> expressions, infinity notes, to describe things like the
> libthread_db.so code. Although the website can only be found in
> archive.org now, the code is still out there:
> https://web.archive.org/web/20190126111943/https://infinitynotes.org/wiki/Infinity
>
> Mailing list: infinity@sourceware.org, 
> https://sourceware.org/ml/infinity/
> Source code: https://gitlab.com/gbenson/i8c/, 
> https://gitlab.com/gbenson/libi8x/

These days, I would recommend to teach GDB to poke at the internal ld.so
data structures to glean the necessary data.  The offsets vary a lot and
would have to come from DWARF, but the structures themselves are fairly
stable (relative to other changes in GDB that glibc updates impose—sorry
about that).

To enable experimentation with this approach, we have stopped removing
debuginfo from ld.so in our distributions.

I kind of want to ship a header-only library in glibc which provides
this capability across multiple glibc versions, while outsourcing the
DWARF parsing etc. to GDB.

libthread_db also had code to compensate for limitations in the original
Linux ptrace interface, but that isn't needed anymore.

Thanks,
Florian


      reply	other threads:[~2022-11-30 18:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24 12:02 Avi Kivity
2022-11-24 12:24 ` Mark Wielaard
2022-11-30 18:46   ` Florian Weimer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkoo46x5.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=avi@scylladb.com \
    --cc=gdb@sourceware.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).