Re: GDB problems
Chris Plummer wrote:
>
> Thiemo Seufer wrote:
> >
> > Chris Plummer wrote:
> > [snip]
> > > (gdb) bt
> > > #0 0xffffffff in ?? ()
> > > #1 0x2aab73c8 in _dl_init () from /lib/ld.so.1
> > > Cannot access memory at address 0x38
> > > (gdb) p $pc
> > > $1 = -1
> > > (gdb)
> >
> > It looks like the dynamic loader forgot to resolve a function entry.
> > Can you try to reduce your App to the smallest testcase where this
> > problem occurs?
> >
> > Thiemo
> >
> Certainly I can try, but it could take a while. This is a very big
> program, and heavily interconnected.
>
> Your suggestion to use -static for my -mips2 problem got me thinking
> that maybe I should try that here also so there are no dll's to load.
> This indeed has fixed the problem. However, this program also requires
> --export-dynamic to lookup some of its own symbols, and -static seems to
> override --export-dynamic and prevent any exports, so now it gets the
> following error from dlopen:
>
> Fatal Error: Could not open testapp as a shared library
>
> In any case, this is a good start. I'll play around with linker flags a
> bit more. I'm still not sure if it is the presence of -static or the
> lack of --export-dynamic that is making the problem go way. In a worse
> case senario I can create a static table of all the symbols the program
> looks up, and just replace dlsym calls with table lookups.
>
> thanks for the help,
>
> Chris
Removing -export-dynamic does not fix the problem. The -static is
needed, so it looks like this is related to resolving one of the
imported symbols.
At this point I don't need to resolve this any further because it turns
out we're ok linking with -static and not having -export-dynamic.
However, if anyone has something they want me to try, I'd be more than
happy to, along as it isn't going to be too time consuming.
Chris Plummer
Reply to: