Is QNX weird or is it just me?

["Kris Warkentin" <kewarken@qnx.com>]

I've discovered the source of some of our single stepping through shared
libs problems.  To remind anyone who hadn't seen my earlier threads, I was
finding that doing a 'step' over a shared library call like printf() was
single stepping all the way through which takes a hellishly long time on a
remote target.

I also discovered that the 'set step-mode on' command was only working on
shared libs other than libc.  This led me down the merry garden path to the
realization that the check IN_SOLIB_DYNSYM_RESOLVE_CODE (which becomes
svr4_in_dynsym_resolve_code in our case) was always returning true for libc.

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'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.

cheers,

Kris