From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11819 invoked by alias); 6 Aug 2011 11:17:28 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 11807 invoked by uid 22791); 6 Aug 2011 11:17:27 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org From: Dodji Seketeli To: Cary Coutant Cc: Tom Tromey , Project Archer , Sterling Augustine Subject: Re: Generating gdb index at link time References: X-URL: http://www.redhat.com Date: Sat, 06 Aug 2011 11:17:00 -0000 In-Reply-To: (Cary Coutant's message of "Fri, 5 Aug 2011 13:30:35 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2011-q3/txt/msg00001.txt.bz2 Hello, Cary Coutant 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). =C2=A0This partic= ular >>> Tom> problem was resolved by you :) saying that we should just change G= CC 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. =C2=A0It may have b= een >>> 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=3D41130 before dropping the ball on this issue. [...] >> >>> Cary> I think the biggest problem is an issue I've seen where the DIE f= or a >>> Cary> class isn't properly nested inside the right context (even after >>> Cary> following DW_AT_specification). There's an ugly workaround for th= is 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. =C2=A0We've tried to file and/or fix problems like this as we've = run >>> across them. =C2=A0There 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. Thanks. --=20 Dodji