X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Wed, 21 Jul 1999 13:13:58 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: Eli Zaretskii cc: djgpp AT delorie DOT com Subject: Re: Bizarre debugging format problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 21 Jul 1999, Eli Zaretskii wrote: > On Tue, 20 Jul 1999, Hans-Bernhard Broeker wrote: > > To put this in context: no, I haven't ever seen this problem with *gdb*, > > only with binutils themselves (objdump -dl, gprof). > > As far as I could see, the BFD function that fetches file names and > source line numbers from COFF debugging info is totally broken. Not totally. It just assumes the wrong 'base' address to translate the offsets found in the symbols to code addresses and vice versa. This base is different for COFF and stabs debug info, which is why you can 'fix' it by using '-gstabs'. I once managed to fix that by adding a constant to the argument of the find_nearest_line call. Regrettably, I seem to have lost that patch, otherwise, I'd have sent it to djgpp-workers for discussion, already. [...] > But GDB doesn't rely on BFD alone for the symtab management, it has > its own, highly complex code that evidently fixes the problems, > because I never saw GDB err or lie about source lines. I've always wondered how on earth GDB manages to get this right, given that the BFD function is clearly buggy. Maybe it detects this (constant) offset by comparing the addresses found in function entry symbols with the ones for the first line number in each function (they're stored relative to function start), or something like that. I'll have to look into gdb sources as well, then... > > I'm currently in the process of packaging up the changes I need for full > > applicability of 'gprof'. > > Do these changes fix the line info problems? I hope they will. I just have to re-discover what that 'magical' offset was, and re-insert it into coff_find_nearest_line(), but after the call to stabs_find_nearest_line() made by it. That's not the only change, though. There are also some others, needed for performance improvement in both the stabs and the COFF case, by caching results. That's needed to avoid having to search the whole list of debug entries for each code address. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.