This is the mail archive of the
mailing list for the Archer project.
Re: Generating gdb index at link time
- From: Dodji Seketeli <dodji at redhat dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Project Archer <archer at sourceware dot org>, Sterling Augustine <saugustine at google dot com>
- Date: Sat, 06 Aug 2011 13:17:02 +0200
- Subject: Re: Generating gdb index at link time
- References: <CAHACq4oHymXfBOqzJfyzQXNyW5PYkN6g65X6x1rMU+YmJybZmQ@mail.gmail.com><email@example.com><CAHACq4ofyavZBt4y65OfYSoeW--HeEAT=sz86urLC0MXBB0hnA@mail.gmail.com><firstname.lastname@example.org><CAHACq4poC0QkGowdHkg0_Y1FRmyXTZZDeoBYrUf91nxz9SJtQw@mail.gmail.com><CAHACq4qhGTg7ShS-eoMHq1oDmoBj=GC=Bx06knVq-+XTUN4ohw@mail.gmail.com>
Cary Coutant <email@example.com> writes:
>>> Tom> This problem was that .debug_pub* are explicitly for public names, but
>>> Tom> for GDB we wanted to see all names (so that "break staticfunction" works
>>> Tom> and "break typo" doesn't cause reading all CUs). ÂThis particular
>>> Tom> problem was resolved by you :) saying that we should just change GCC to
>>> Tom> emit all the names.
>>> Cary> No one has actually changed GCC to do that, yet, though -- right?
>>> I think either Dodji or I had a patch at one point. ÂIt may have been
>>> part of Dodji's patch to change .debug_pub* to also include all the
>>> extra info we thought we needed at the time.
>>> I'm not sure if it is still around.
>> If you can find it, we'd definitely be interested in it.
I stored the iterations of that patch as attachments to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130 before dropping the
ball on this issue.
>>> Cary> I think the biggest problem is an issue I've seen where the DIE for a
>>> Cary> class isn't properly nested inside the right context (even after
>>> Cary> following DW_AT_specification). There's an ugly workaround for this in
>>> Cary> gdb (by looking for a member subprogram with a linkage name, and
>>> Cary> extracting the class name from that), which I copied into gold. As
>>> Cary> part of this work, I'd like to fix that bug in GCC, and any others
>>> Cary> like it.
>>> Yeah. ÂWe've tried to file and/or fix problems like this as we've run
>>> across them. ÂThere are still some open bugs around naming.
I'd be interested in looking into these nesting bugs when I have some
free cycles. Please CC me on these.