Re: EH Performance

[Geoff Keating <geoffk at cygnus dot com>]

"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> Also, your assertion that the mechanism initializes *all* of the
> shared objects (DSO) in the entire application; it does not. It only
> processes them in list order until it finds the DSO in which the PC
> currently lives. It is necessary to initialize all those DSOs even if
> they are not the origin of the exception because there is no run-time
> information where the shared library lives in address space. If it was
> possible to find out the exact range of all code segments of a DSO at
> run time (or find out lower and upper boundaries), then DSOs could be
> skipped if they clearly are not the origin of the exception. I'm not
> sure what kind of magic that involves, but it seems that the dynamic
> linker would have to play a role here.

On Linux, you could, but for namespace and linking issues, use the
dladdr() function to find out which shared object an address is in.

> LSCIE1:
> 	.4byte	0x0
> 	.byte	0x1
> 	.string	"eh"
> 
> 	.4byte	__EXCEPTION_TABLE__
> 
> It may be possible to use a relative offset from the CIE to the
> exception table, which could be filled-in by the linker, i.e.
> 
> 	.4byte	__EXCEPTION_TABLE__ - .LSCIE1
> 
> The linker experts would need to comment whether that can be done with
> proper relocations; the simple approach above fails as the symbols are
> from different sections. If that can be solved in some way, then the
> runtime could certainly interpret the value as a delta; it probably
> needs a different magic string to do so.

I would expect that all platforms that support shared libraries can
handle a PC-relative relocation.  I'm not sure about a PC-relative
_misaligned_ relocation, that's less likely to work.

However, we can't change this immediately on Linux because that would
break binary compatibility.

> Also note that a new C++ ABI is currently underway, which also
> includes a new unwinding mechanism. Even though the ABI is primarily
> designed for ia64, g++ will likely use it on other platforms as well.

This would be the ideal time to make such a change.

-- 
- Geoffrey Keating <geoffk@cygnus.com>