Re: Is QNX weird or is it just me?

[Kevin Buettner <kevinb at redhat dot com>]

On Aug 26, 10:50am, Kris Warkentin wrote:

> Judging by the code for svr4_in_dynsym_resolve_code, I believe that the
> issue is the fact that all our dynamic linker code is stored in our libc.
> In fact, ld-qnx.so is just a link to libc.so.  Is this weird or are there
> other systems that do this?

I've worked on at least one other system in the past which put the dynamic
linker in libc.so.  (I can only remember one at the moment.  That one was
weird.)

> I'm just wondering if anyone can think of some way to write a replacement
> for svr4_in_dynsym_resolve_code that would actually work properly in this
> case.  I suppose I could use the bfd to check and see if we're within the
> bounds of the object where our ldd() function is but even that doesn't work
> perfectly.  After all, ldd() calls out to other objects as well.
> 
> In some respects this isn't a critical issue because we do all our library
> loading at startup (got to keep it real time deterministic don't you
> know...) but there is still the dlopen/dlsym thing.  I suppose I could just
> cheat and define the function to always return false.  This solves the
> majority of the problems and I don't think will create many (if any) new
> ones.
> 
> I'm thinking that we might be stuck with actually needing to separate
> ld-qnx.so from libc.so to get it working right but perhaps there are some
> clever ideas about.

Separating the dynamic linker out of libc.so seems like the most
straightforward route to go.  Another idea though: if your dynamic
linker could set some flag when it's working and reset it when it's
not, perhaps you could have gdb read the memory associated with the
flag?  Of course, that'd mean doing a target memory read every time
qnx_in_dynsym_resolve_code() is called...

Kevin