Re: just checked in

[Roland McGrath <roland@frob.com>]

> The "easy" part of the changes consisted of handling the `catch'
> variable in dl-error.c.  It also wasn#t that easy since the relocation
> of ld.so itself does not know about weak symbols.  See the ugly hack I
> had to add.

Such an ugly hack should be a sign that there must be a better way to solve
the root problem.

I would like to avoid using thread-specific data for this (and for anything
that doesn't really require it).  It is clunky in various ways and brings
in all sorts of hair, especially in the dynamic linker with its
bootstrapping issues.

Since in this case there no need for thread-granularity data, just
temporary data during a single call, and these are all internal interfaces
that we can change, there is no need to use thread-specific data.

I think we should replace the use of thread-specific data with one of two
schemes:

1. Add an `error_receiver' arg to each _dl_* function, passed down in all
   the internal calls.  The top-level calls such as dlopen et al (or in
   _dlerror_run, or whatever) will do:
	struct dl_error_receiver error = { blah blah };
	... = _dl_open(&error, ...);
   The structure can contain (or point to) the jmp_buf or whatever.

2. Punt the exception-throwing model and use explicit error returns for all
   the _dl_* functions.  This would be similar to above, but we'd change
   every function to return an error code or zero for success, and calls
   _dl_signal_error would be replaced with a macro to set the error-detail
   fields in the `error_receiver' structure, and return the error code.
   Every internal call would need to do `if (rc) return rc;'.

In either case _dl_signal_error or the frob replacing it can implement the
_dl_receive_error functionality by (#1) not jumping as it does now or (#2)
not returning.

I know this changes a bunch of interfaces, but they are all internal
interfaces, and I find these barbarous hacks and wasteful unnecessary use
of a word for each thread much more distasteful than that.

Do you see a problem with my suggestion?


Thanks,
Roland