Re: [Various] libc/1609: Error in 'make check' origtest with testobj1.so

[Solar Designer <solar at false dot com>]

> 
> > Actually, it's possible Ulrich can answer this question without you
> > having to try.  Does glibc 2.1 itself still use trampolines in some
> > place that's critical to get a system running?  Does it require that
> > trampolines work while it's being compiled?
> 
> We have in the source code some nested functions but they all should
> be optimized away or inlined.  Of course you must not compile without
> optimization.  -O2 is always advised.

Nested functions by themselves don't result in trampolines anyway.
Trampolines are only needed for calling a nested function from the
outside (the only legitimate way to do so is via a function pointer).

So, it should be possible to reproduce the problem running with the
trampoline support in my patch disabled.  That way we could be sure
the problem isn't in that code (I am already fairly sure of that, but
there's no proof, yet).

> > This can cause some application bugs or limitations to show up.
> > This can well be a bug in my code, I'm just pointing out that we
> > can't be sure of that, yet.
> 
> There are no such dependencies.  We use the same code on different
> platforms which use different shared lib positions.  Also, loading
> shared objects (including ld.so) in different orders gives different
> load addresses.  I'm pretty sure this cannot be the problem.

Well, I've seen one case where this turned out to be the problem so
far.  If not that, then the bug could be in my replacement signal
handling code.  Those two are the only changes that could be visible
from the user-space (the signal handling change is in fact supposed
to be transparent).

Signed,
Solar Designer