A problem with SPARC backend & purify

[Ewgenij Gawrilow <gawrilow at math dot TU-Berlin dot DE>]

Dear SPARC gurus,

you had surely got serious reasons to change the code generation in PIC mode
dealing with situations where an absolute address must be taken. Where the
egcs 1.0.3 has used to emit something of the kind

	call  .+8
	sethi %hi(ADDR), %l7
	or    %lo(ADDR-.-8), %l7
	add   %l7, %o7, %l7

the newer versions produce a call to a dwarf two-line subroutine that lands
later somewhere in the .fini section. This change had remained fully unnoticed
if all programs prepared by purify would not brutally crash yet before main() is
being entered - in the .init routine of libstdc++.so

The cause is that purify isn't aware of the special role of such a subroutine.
Therefore it doesn't fix the offset values being loaded in %l7 as it should do,
since the ADDR has been moved in the prepared code. The old good construct
"call .+8" is known to purify, so the programs compiled with <=1.0.3 has been
prepared correctly.

As I appreciate both egcs and purify very much and don't want to miss any of
them, here my impolite question: would it be possible to revert the ecgs'
behaviour to the old fashion or, at least, to introduce an option (disabled by
default) controlling this? If not, can this super-secret subroutine be marked
somehow in the object code (with a special local name, or some debugging info),
so that purify gets a chance to recognize the calls to it and to proceed
properly? (In the latter case an additional difficult task arises to implore
the purify developers to build in this feature. Have you somewhat regular
contact to the folks?)

With best regards,
Ewgenij Gawrilow
Math Department,
Technical University Berlin