Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - ldd.c error() and resolve_error_funcs(): (3 Items)
   
ldd.c error() and resolve_error_funcs()  
With the advent of the various x*() functions which have been added to ldd.c via xsupport.ci, does anyone know if we 
need to retain error() and resolve_error_funcs().  (For example, could we just call xerrx() instead?)

Conversely, if error() is still needed, should the x*() functions be using a similar relocation strategy for their 
externals (e.g. write(), exit(), sys_nerr, sys_errlist[], etc.).  (They also make use of stdarg.h, which I assume 
requires no relocations on any of our target platforms.)

As I understand it (probably incorrectly :-) error() was introduced to address PR 14918 which seems to have dealt with 
the possibility of write() and friends being tied to the executable's GOT (presumably via a PLT entry) before that GOT 
was properly initialized - at least on some architectures.  Have I got that right?

I would guess that the only point at which this is a serious problem is during the initial resolve(&bootstrap) - after 
that the worst that would happen is we'd be pointing to the "wrong" write() etc. if interposed shared objects exist.  
OTOH, resolve() is generic code that's called from various places, so a "one size fits all" solution might be simplest 
and safest anyway.

On a related note, xerr() and xerrx() both currently call exit().  It would probably be safer to call _exit() from these
 given the context that they're expected to be called from (e.g. stdio cleanup is probably a bad idea, likewise any 
atexit() processing).

Re: ldd.c error() and resolve_error_funcs()  
Anyone?  Bueller, Bueller?
Re: ldd.c error() and resolve_error_funcs()  
I'm sorry, I've got a racecar to drive, a neurotic friend to liberate from his inhibitions, and that
SMP scalability assignment due in on my teachers desk...

:-)

Neil Schellenberger wrote:
> Anyone?  Bueller, Bueller?
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post25136
> 

-- 
cburgess@qnx.com