Mail Archives: djgpp-workers/2000/12/07/14:10:18
On Thu, 7 Dec 2000, Eli Zaretskii wrote:
> On Thu, 7 Dec 2000, Hans-Bernhard Broeker wrote:
> addr2line is badly broken, I needed to repair some of its code when I
> wrote bfdsymify (which is based on addr2line). I don't remember the
> details, but it had to do with printing something reasonable for library
> functions for which there's no debug info in the executable.
So the first step would be to try and get those changes back go into the
Binutils sources, I'd say. There's no point having the changes at hand and
not filing them back to the binutils team, IMHO.
[...]
As bfdsymify uses an existing tool from binutils, I don't think there's
much sense in adding bfdsymify itself to that package. All the
binutils-specific parts of bfdsymify needs should be handled by addr2line,
so bfdsymify should be independant of the binutils.
We'ld just have to make sure that addr2line works correctly.
> I meant to add core file support to bfdsymify, so that it would read the
> core file and print the stack traceback, exactly like GDB (or any other
> debugger) does on Unix. AFAIK, this particular feature is not part of
> BFD, and GDB is IMHO too large to tell users to use it just to get a
> traceback. (GDB also uses lots of its own code to read symbols,
> bypassing the equivalent BFD code.)
In that case, the updated version of bfdsymify should probably be built
from a subset of the GDB sources, and hence become a member of the GDB
package, not of binutils. It's essentially a special-purpose micro-gdb,
after all.
[BTW: other programs also seem to do their own core file reading rather
than using the BFD --- e.g. gprof.]
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -