Tracing a library symbol back to source code line.

Tracing a library symbol back to source code line.

Post by heitk.. » Fri, 03 Jan 2003 04:51:57



(I appologize in advance if this is a silly question.)

How would I trace back a library symbol to the line of code
that created it?  I have tried the --cref option to the
linker, but that did not seem to work. I am using
GCC on Linux.

For instance, in a library I am compiling (SDL 1.2.6), the
resultant library has an undefined symbol
libSDL-1.2.so.0.0.6:         U __ctype_b

The fact that the symbol is undefined is irrelevant to my
question.

Somewhere in the source code is a call to a ctype routine
like isspace for instance, that is causing that symbol to
be added to the library.  How do I find which source code
line is responsible?

Fred

 
 
 

Tracing a library symbol back to source code line.

Post by Michael B. Alle » Fri, 03 Jan 2003 06:10:37




> (I appologize in advance if this is a silly question.)

> How would I trace back a library symbol to the line of code that created
> it?  I have tried the --cref option to the linker, but that did not seem
> to work. I am using GCC on Linux.

> For instance, in a library I am compiling (SDL 1.2.6), the resultant
> library has an undefined symbol libSDL-1.2.so.0.0.6:         U __ctype_b

> The fact that the symbol is undefined is irrelevant to my question.

> Somewhere in the source code is a call to a ctype routine like isspace
> for instance, that is causing that symbol to be added to the library.
> How do I find which source code line is responsible?

Everything is located by offsets so you cannot get line numbers unless
you map offsets to the source like GDB does. You could narrow it down to
which .o file it is by using objdump. For example I have a library
consisting of ~10 modules. Runing objdump -t on my cfg.o module gives:


cfg.o:     file format elf32-i386

SYMBOL TABLE:
00000000 l    df *ABS*  00000000 cfg.c
00000000 l    d  .text  00000000
00000000 l    d  .data  00000000
00000000 l    d  .bss   00000000
00000000 l       .text  00000000 gcc2_compiled.
00000088 l     F .text  0000009f readline
00000128 l     F .text  0000010a validateline
00000000 l    d  .rodata.str1.1 00000000
00000000 l       .rodata.str1.1 00000000 .LC0
0000000a l       .rodata.str1.1 00000000 .LC1
0000000c l       .rodata.str1.1 00000000 .LC2
00000011 l       .rodata.str1.1 00000000 .LC3
0000001d l       .rodata.str1.1 00000000 .LC4
0000001f l       .rodata.str1.1 00000000 .LC5
00000000 l    d  .note  00000000
00000000 l    d  .comment       00000000
00000000 g     F .text  00000055 cfg_new
00000000         *UND*  00000000 _GLOBAL_OFFSET_TABLE_
00000000         *UND*  00000000 malloc
00000000         *UND*  00000000 linkedlist_new
00000000         *UND*  00000000 __errno_location
00000000         *UND*  00000000 msgno_hdlr_mno
00000058 g     F .text  00000030 cfg_del
00000000         *UND*  00000000 free
00000000         *UND*  00000000 linkedlist_del
00000000         *UND*  00000000 fgetc
00000000         *UND*  00000000 __ctype_b
00000234 g     F .text  00000125 cfg_load
00000000         *UND*  00000000 fopen
00000000         *UND*  00000000 msgno_hdlr_mnf
00000000         *UND*  00000000 __strdup
00000000         *UND*  00000000 linkedlist_add
00000000         *UND*  00000000 msgno_hdlr_msg
00000000         *UND*  00000000 fclose
0000035c g     F .text  000000b8 cfg_store
00000000         *UND*  00000000 linkedlist_iterate
00000000         *UND*  00000000 fputs
00000000         *UND*  00000000 fputc
00000000         *UND*  00000000 linkedlist_next
00000414 g     F .text  000001ed cfg_get_str
00000000         *UND*  00000000 memcpy
00000000         *UND*  00000000 strncpy
00000604 g     F .text  00000088 cfg_vget_str
00000000         *UND*  00000000 vsnprintf
0000068c g     F .text  000000a5 cfg_get_int
00000000         *UND*  00000000 __strtol_internal
00000734 g     F .text  00000084 cfg_vget_int

Quote:

> Fred

--
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.

 
 
 

Tracing a library symbol back to source code line.

Post by Hasan Azam Diwan From » Fri, 03 Jan 2003 06:10:39



>How would I trace back a library symbol to the line of code
>that created it?  I have tried the --cref option to the
>linker, but that did not seem to work. I am using
>GCC on Linux.

        Compile the binary with debugging symbols and use gdb, when the program
crashes, keep pressing 'u' (Up) till you see something recognizable.
--
Hasan =)
PGP Key: http://www.cs.rpi.edu/~diwanh/pgp.key
 
 
 

Tracing a library symbol back to source code line.

Post by heitk.. » Fri, 03 Jan 2003 22:15:13




>>How would I trace back a library symbol to the line of code
>>that created it?  I have tried the --cref option to the
>>linker, but that did not seem to work. I am using
>>GCC on Linux.

>        Compile the binary with debugging symbols and use gdb, when the program
>crashes, keep pressing 'u' (Up) till you see something recognizable.

Unfortunately, I don't get the binary compiled because the linker
complains about the undefined symbols and quits.

--

Fred

Error Loading Explorer.exe
You must reinstall Windows.

 
 
 

Tracing a library symbol back to source code line.

Post by Chuck Dillo » Fri, 03 Jan 2003 23:55:11



> Somewhere in the source code is a call to a ctype routine
> like isspace for instance, that is causing that symbol to
> be added to the library.  How do I find which source code
> line is responsible?

Grep comes to mind. You can use nm on the .o files to find the
undefined references at that resolution and then grep.

You could try linking in your own version of the symbol so that you can
build an executable and use a de*.

-- ced

--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

 
 
 

Tracing a library symbol back to source code line.

Post by Bjorn Rees » Sat, 04 Jan 2003 02:24:31



> Somewhere in the source code is a call to a ctype routine
> like isspace for instance, that is causing that symbol to
> be added to the library.  How do I find which source code
> line is responsible?

Try 'nm -l' (may require the GNU binutil version)