On Thu 29 Aug 2013 10:52:49 NZST +1200, Derek Smithies wrote:
but the same code compiled without debug fails. Turned out in that
case that the debug code had larger stack sizes
and could cope with very large arrays being placed on the stack.
Memory allocation is system specific I believe, i.e. your program simply
accesses an address outside its allocated memory range, and the OS
decides how far is too far and whether to allocate more pages or send a
SIGSEGV. You get around this by dummy accesses in steps.
The question is: does anyone know of a way of taking a segfault
address (from release version code) and determing the
offending line of C code?
Do you have the source code?
Can one generate a map (at compile time)
that relates addresses to lines of code...
You can put
-Wl,-Map=mapfile
into the link command, but this shows how the final executable is
layed out, and does not allow for a correlation to individual lines.
This information is exactly what -g puts into the executable. If you
didn't compile with -g, you don't have that info available, and the only
way to get it is to recompile in a way that results into identical
addresses (good luck - compiler, C library, header versions...).
It seems that one should create a map at the time of compile each
source file - but have not seen such an option...
One should save a copy compiled with -g.
You can get the symbol maps with nm, but only for symbols still in the
executable - so if you stripped it to death, you'll only get the symbols
required for dynamic linking. nm may be able to produce fake symbols,
i.e. some letter with a large number following, but that doesn't help
you.
I haven't heard of a binary-to-C reverse compiler, at least not open
source.
For sure, with optimisation turned on, the assembly instructions
have no direct correlation to lines of code - which makes it a
doubly
hard question..
Indeed. It also makes debugging very difficult (if not pointless) at
times, and line numbers tend to be at best approximate.
The best you can do is identify the function the segv occurred in, from
then you're into a lot of pain involving disassemblers and binary
poking. Easier to recompile the source, if you can. You may be able to
identify clusters of assembly instructions belonging to clusters of C
code, if the recompilation is not exact.
If you don't have the source, you're in for one hell of a ride through
the bytes and bits, C64 style, except with lot more pain.
Volker
