How to tell where a symbol is satisfied from.

[Patrick Doyle]

On 12/27/06, Reg Clemens <reg at dwf.com> wrote:
> > Reg Clemens wrote:
> > > How do I find out where this symbol is defined???
> >
> > env LD_DEBUG=bindings ./a.out
> >
> > Note that this does not work for prelinked binaries since they don't
> > perform relocations.
> >
>
> Mabe Im asking the wrong question, let me start again.
>
> If I compile the following piece of code with gcc -c
>
> ---
>
> #define MULMOD(x,y,p) ((int) ((((long long) (x)) * ((long long) (y))) % ((long
> long) (p))))
>
> main()
> {
>         long long x, y, p;
>         int     i;
>
>         x = 2;
>         y = 3;
>         p = 4;
>
>         i = MULMOD (x, y, p);
> }
>
> ---
>
> (where the values assigned to x,y,p are irrelevant), and then do a nm on
> test.o, I get
>
> [reg at deneb ~]$ nm test.o
>          U __moddi3
> 00000000 T main
>
> Showing moddi3 is undefined.
> If I compile and load with gcc test.c, then neither of the suggestions in the
> previous
> two notes tell me where moddi3 is coming from.
>
> The real question I am asking here is this:
> I have another,much larger, piece of code that calls the fttw library which I
> just (re)compiled under fc6.
> When I try to compile this piece of code, it shows moddi3 as being
> UNDEFINED.
> (it is being referenced from the library routines, not the main routine).
>
> I was hoping to find where it (moddi3) was defined, and then add that to the
> libraries mentioned on the compile line, but have yet to figure out where it
> is.
>
> Suggestions???
moddi3 is an internal function called by gcc, (most likely to divide
long long integers, but I'd have to go poke around to double check
that, for now, let's assume I'm correct).  The compiler emits a call
to moddi3 when it realizes that it doesn't have a built in instruction
(or a built in optimization that would emulate that instruction) to
divide 2 long longs.  As such, there is a gcc-support libirary

Having said that, I would guess that gcc bumped up a rev on fc6 over
what you were running previously, that the new gcc on the new machine
knows how to divide 64 bit integers (perhaps you're running on a 64
bit machine?), and that you have some code leftover from your previous
machine that was compiled with the older gcc.  Alternatively, some of
your code might be compiled for a 32 bit architecture and some for a
64 bit architecture.

Anyway, those are my random guesses based upon my knowledge of why gcc
emits calls to functions with names like moddi3, and the fact that
you've mentioned an upgrated to fc6 (which I am not running).

perhaps this helps...

--wpd