Date: Wed, 21 Jul 1999 17:03:02 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker 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, Hans-Bernhard Broeker wrote: > Not totally. It just assumes the wrong 'base' address to translate the > offsets found in the symbols to code addresses and vice versa. That's not what I saw in my testing. When passed an address in a function compiled with -gcoff, it usually returns correct source file and line information. As far as I could see, it correctly takes the base line number for a function from the first line info symbol for that function. But when faced with address in a function compiled without -g, it goes bananas. > I've always wondered how on earth GDB manages to get this right, > given that the BFD function is clearly buggy. In the same way our libdbg.a does it: it simply doesn't use the xxx_find_nearest_line functions from BFD. Instead, it reads the symbols via BFD, and then processes them, including the line number info, using its own code. > 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. coff_find_nearest_line does that as well. I suspect that it errs when it falls off the end of the end of the loops that search the symtab for the nearest function and line number. But that's a hunch at best, and even it doesn't explain some of the creative output I've seen from "nm --lines".