Is QNX weird or is it just me?

Is QNX weird or is it just me?

[Kris Warkentin]

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

Re: Is QNX weird or is it just me?

[Kevin Buettner]

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

Re: Is QNX weird or is it just me?

[Kris Warkentin]

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

Well, I tested the override of qnx_in_dynsym_resolve_code() to just return 0
and it doesn't seem to have any ill effects that I can see.  We don't do
lazy linking and aren't planning to any time in the future.  The
dlopen/dlsym thing didn't seem to have any trouble either so I'm just taking
the easy solution for now and leaving a note to myself to re-examine it if
we ever implement late binding.

The flag idea is not bad but you're right about the inefficiency.
Considering that the IN_DYNSYM_CODE is called for every step, it could slow
things down a fair bit if I had to make an extra call.  I bet if I
encapsulated the flag in one of our packets that needs to go across the wire
every step anyway,  and just check it as it comes in; that would work
though.  Thanks.

cheers,

Kris