Define [CD]TORS_SECTION_ASM_OP on Solaris/x86 with Sun ld

While investigating why many libmudflap execution tests failed on
Solaris 11/x86 with Sun ld, but succeeded on Solaris 11/SPARC, I came
across the following:

The first failure is fail17-frag.  With MUDFLAP_OPTIONS=-trace-calls, I see

mf: __mfwrap_strcpy
mf: check ptr=8050f8c b=995 size=10 read location=`(strcpy src)'
mf: violation pc=fee8894d location=(strcpy src) type=1 ptr=8050f8c size=10
*******
mudflap violation 1 (check/read): time=1310040104.249932 ptr=8050f8c size=10
pc=fee8894d location=`(strcpy src)'

The constant string isn't ever registered here, thus the failure.

With gld instead, I see no failure

mf: __mfwrap_strcpy
mf: check ptr=8048bac b=747 size=10 read location=`(strcpy src)'

and the string is registered very early:

mf: register ptr=0 size=1 type=0 name='NULL'
mf: register ptr=8048bac size=10 type=4 name='string literal'

This registration is from tree-mudflap.c (mudflap_enqueue_constant),
emitted at the end of mudflap_finish_file via

  cgraph_build_static_cdtor ('I', ctor_statements,
                             MAX_RESERVED_INIT_PRIORITY-1);

With gld, the registration function _GLOBAL__sub_I_00099_0_main is
entered into a .ctors section, but with Sun ld I find separate .ctors
and .ctors.65436 sections.  varasm.c (get_cdtor_priority_section), which
is called by default_named_section_asm_out_constructor, states:

  /* ??? This only works reliably with the GNU linker.  */

This is obviously true: Sun ld doesn't coalesce different .ctors.N
sections, thus the contructor isn't called.

On Solaris 11/SPARC instead, CTORS_SECTION_ASM_OP is defined in
sparc/sysv4.h, and thus default_ctor_section_asm_out_constructor is
called.

The obvious solution is to define [CD]TORS_SECTION_ASM_OP on Solaris/x86
with Sun ld, too.  And indeed this fixes all remaining libmudflap
failures.

On the other hand, there's the question why tree-mudflap.c tries to
create a constructor with a non-default priority on a platform with
SUPPORTS_INIT_PRIORITY == 0 or at all: it seems that all is fine even
with init_priority ignored.  Either mudflap_enqueue_constant should
check for this condition, or at least the middle-end should emit an
error or a warning in this case.

I've bootstrapped the following patch without regressions on
i386-pc-solaris2.11 (Sun as/ld) and i386-pc-solaris2.8 (GNU as/ld)
without regressions.

Installed on mainline.

	Rainer


2011-07-08  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* config/i386/sol2.h [!USE_GLD] (CTORS_SECTION_ASM_OP): Define.
	(DTORS_SECTION_ASM_OP): Define.

Hi, Rainer -

On Mon, Jul 11, 2011 at 06:34:27PM +0200, Rainer Orth wrote:
> [...]
> On the other hand, there's the question why tree-mudflap.c tries to
> create a constructor with a non-default priority on a platform with
> SUPPORTS_INIT_PRIORITY == 0 or at all [...]

For the "at all" part, I believe the intent was to make it more likely
that mudflap-tracked literals be tracked early enough so that other
constructors would find them already available for checking.

- FChE

Hi Frank,

> On Mon, Jul 11, 2011 at 06:34:27PM +0200, Rainer Orth wrote:
>> [...]
>> On the other hand, there's the question why tree-mudflap.c tries to
>> create a constructor with a non-default priority on a platform with
>> SUPPORTS_INIT_PRIORITY == 0 or at all [...]
>
> For the "at all" part, I believe the intent was to make it more likely
> that mudflap-tracked literals be tracked early enough so that other
> constructors would find them already available for checking.

I see.  I'm still undecided who's responsibility it is to deal with the
!SUPPORTS_INIT_PRIORITY case.  On one hand one might argue that only the
callers can decide if a non-default priority is strictly required or
just an improvement, OTOH silently ignoring the priority and causing
constructors not to be run at all doesn't seem a winning proposition
either ;-)

	Rainer