line numbers in stack trace

[[e-mail]]

If I write a C program under Linux and compile it
with "gcc -g" and then run it under "catchsegv",
it displays the line number of the failing
instruction (which I deliberately invoked by
going *(char *)0 = 0; ).

But when I build a shared library (.so) with "-g"
and then have Java execute it as a JNI, it is
Java that intercepts the SIGSEGV and in that
stack trace I don't have any line numbers, just
hex offsets.

What is the process by which line numbers
magically appear? Who is doing what?

One thing I could try is compiling with "-dA" and
see if I can get an assembly listing with line
numbers and then presumably the assembler
"as" can produce a listing with all the offsets. I
haven't tried that. Maybe that is in fact the proper
thing to be doing instead of attempting to do the
match at runtime?

Thanks. Paul.

[Scott Lurndal]

Post by ***@gmail.com
If I write a C program under Linux and compile it
with "gcc -g" and then run it under "catchsegv",
it displays the line number of the failing
instruction (which I deliberately invoked by
going *(char *)0 = 0; ).
But when I build a shared library (.so) with "-g"
and then have Java execute it as a JNI, it is
Java that intercepts the SIGSEGV and in that
stack trace I don't have any line numbers, just
hex offsets.
What is the process by which line numbers
magically appear? Who is doing what?

There is a DWARF section in the ELF file. The DWARF
section contains the line number to code address mappings as well
as the debug symbol table.

Very few utilities outside of GDB understand DWARF.

[[e-mail]]

Post by ***@gmail.com
What is the process by which line numbers
magically appear? Who is doing what?

There is a DWARF section in the ELF file. The DWARF
section contains the line number to code address mappings as well
as the debug symbol table.
Very few utilities outside of GDB understand DWARF.

Thanks a lot for the explanation Scott. Exactly what
I needed to know.

BFN. Paul.