Unreviewed build/libgcc, mudflap patches

Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

The following three patches have remained unreviewed for a week:

	[build] Move unwinder to toplevel libgcc
        http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html

This needs at least a build and/or libgcc maintainer, though a global
reviewer might be helpful.  I'm not Cc'ing the various affected target
or runtime library maintainers here, though unfortunately none of them
has commented in any way ;-(

	[ada, build] Link gnattools with $(LIBINTL)
        http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01443.html

This needs a build and/or Ada maintainer.  I guess this is obvious,
though.

	Support libmudflap on Solaris (PR libmudflap/38738)
        http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html

This needs the mudflap maintainer.

Thanks.
	Rainer	

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed build/libgcc, mudflap patches

[Frank Ch. Eigler]

Hi -

On Mon, Jun 27, 2011 at 01:32:30PM +0200, Rainer Orth wrote:
> [...]
> 	Support libmudflap on Solaris (PR libmudflap/38738)
>         http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html

Looks good to me, thanks for taking a look at the area.

- FChE

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Hi Frank,

> On Mon, Jun 27, 2011 at 01:32:30PM +0200, Rainer Orth wrote:
>> [...]
>> 	Support libmudflap on Solaris (PR libmudflap/38738)
>>         http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
>
> Looks good to me, thanks for taking a look at the area.

Could you also comment on the open questions in the submission so
mudflap support on Solaris can be improved further?

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed build/libgcc, mudflap patches

[Frank Ch. Eigler]

Hi -

> >>         http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
> > Looks good to me, thanks for taking a look at the area.
> 
> Could you also comment on the open questions in the submission so
> mudflap support on Solaris can be improved further?

Sure.  Transcribing:

> One generic issue came up with the port: enabling or disabling
> libmudflap depends on a factor (linker support for --wrap/-z wrap)
> that is best checked dynamically, thus doesn't really seem to belong
> at the toplevel.  Is there any precedent for performing such a test
> in the target library and enabling or disabling depending on the
> outcome?  [...]

I don't know.

> It seems the failures fall into only a few categories.  It's
> probably best to analyse and fix those before checking in the patch.
> Where should we continue discussing the failures?  Here or rather in
> the PR?

Separate PRs would be best.

- FChE

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Hi Frank,

> Sure.  Transcribing:
>
>> One generic issue came up with the port: enabling or disabling
>> libmudflap depends on a factor (linker support for --wrap/-z wrap)
>> that is best checked dynamically, thus doesn't really seem to belong
>> at the toplevel.  Is there any precedent for performing such a test
>> in the target library and enabling or disabling depending on the
>> outcome?  [...]
>
> I don't know.

perhaps one of the build maintainers has a suggestion.  For the time
being, I'll juts continue with --enable-libmudflap.

>> It seems the failures fall into only a few categories.  It's
>> probably best to analyse and fix those before checking in the patch.
>> Where should we continue discussing the failures?  Here or rather in
>> the PR?
>
> Separate PRs would be best.

I've now filed

libmudflap/49549	Use of --noinhibit-exec is unportable
libmudflap/49550	Many libmudflap tests fail on Solaris 11/x86

The second one almost certainly covers a couple of different issues, but
I cannot identify them yet, so any help is appreciated.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Hi Frank,

>> 	Support libmudflap on Solaris (PR libmudflap/38738)
>>         http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
>
> Looks good to me, thanks for taking a look at the area.

I've installed the patch as it, since it at least fixes the libmudflap
build on Solaris.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed build/libgcc, mudflap patches

[Iain Sandoe]

Hi Rainer,

On 27 Jun 2011, at 12:32, Rainer Orth wrote:

> The following three patches have remained unreviewed for a week:
>
> 	[build] Move unwinder to toplevel libgcc
>        http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html
>
> This needs at least a build and/or libgcc maintainer, though a global
> reviewer might be helpful.  I'm not Cc'ing the various affected target
> or runtime library maintainers here, though unfortunately none of them
> has commented in any way ;-(

As far as Darwin is concerned, there do not appear to be any problems.

The patch bootstraps on *-darwin9 and x86_64-darwin10 and reg-tested  
on i686-darwin9 with no issues.

having said this .. I can neither approve nor reject the patch ;-)

===

If you get as far as pushing the .ver files around, then I have some  
tidy-ups I'd like to incorporate (particularly with respect to gcc/ 
libgcc-libsystem.ver which is in a funny place, and contains extra  
symbols that are only used AFAIK by x86 darwin10).

Iain

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Hi Iain,

>> The following three patches have remained unreviewed for a week:
>>
>> 	[build] Move unwinder to toplevel libgcc
>>        http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html
>>
>> This needs at least a build and/or libgcc maintainer, though a global
>> reviewer might be helpful.  I'm not Cc'ing the various affected target
>> or runtime library maintainers here, though unfortunately none of them
>> has commented in any way ;-(
>
> As far as Darwin is concerned, there do not appear to be any problems.
>
> The patch bootstraps on *-darwin9 and x86_64-darwin10 and reg-tested on
> i686-darwin9 with no issues.

great, thanks for testing.

> having said this .. I can neither approve nor reject the patch ;-)

Even so, every bit of assurance that this won't break many platforms helps.

> If you get as far as pushing the .ver files around, then I have some
> tidy-ups I'd like to incorporate (particularly with respect to gcc/
> libgcc-libsystem.ver which is in a funny place, and contains extra  symbols
> that are only used AFAIK by x86 darwin10).

No such plans at the moment: my primary motivation is to deal with
issues that affect platforms I maintain.  While I can test Darwin 9 if
need be, I'd rather restrict my time to my `own' platforms.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed build/libgcc, mudflap patches

[Mike Stump]

On Jun 27, 2011, at 9:54 AM, Iain Sandoe wrote:
> On 27 Jun 2011, at 12:32, Rainer Orth wrote:
> 
>> The following three patches have remained unreviewed for a week:
>> 
>> 	[build] Move unwinder to toplevel libgcc
>>       http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html

> As far as Darwin is concerned, there do not appear to be any problems.

Darwin bits are Ok.

Re: Unreviewed build/libgcc, mudflap patches

[Arnaud Charlet]

> 	[ada, build] Link gnattools with $(LIBINTL)
>         http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01443.html
> 
> This needs a build and/or Ada maintainer.  I guess this is obvious,
> though.

Can you clarify how LIBINTL is set, and to what value? Will it be empty
when not needed?

Arno

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Arnaud,

>> 	[ada, build] Link gnattools with $(LIBINTL)
>>         http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01443.html
>> 
>> This needs a build and/or Ada maintainer.  I guess this is obvious,
>> though.
>
> Can you clarify how LIBINTL is set, and to what value? Will it be empty
> when not needed?

It's substituted in gcc/ada/gcc-interface/Makefile.in:

LIBINTL = @LIBINTL@

On Solaris 10, it becomes ${top_builddir}/../intl/libintl.a, on Solaris
11, it is empty.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Unreviewed build/libgcc, mudflap patches

[Arnaud Charlet]

> >> 	[ada, build] Link gnattools with $(LIBINTL)
> >>         http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01443.html
> >>         
> >> 
> >> This needs a build and/or Ada maintainer.  I guess this is obvious,
> >> though.
> >
> > Can you clarify how LIBINTL is set, and to what value? Will it be empty
> > when not needed?
> 
> It's substituted in gcc/ada/gcc-interface/Makefile.in:
> 
> LIBINTL = @LIBINTL@
> 
> On Solaris 10, it becomes ${top_builddir}/../intl/libintl.a, on Solaris
> 11, it is empty.

The patch is OK then, thanks.

Re: Unreviewed build/libgcc, mudflap patches

[Paolo Bonzini]

On 06/27/2011 01:32 PM, Rainer Orth wrote:
> 	Support libmudflap on Solaris (PR libmudflap/38738)
>          http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
>
> This needs the mudflap maintainer.

Build changes are okay, the rest is pretty obvious.

For pass-stratcliff I'd rather use autoconf tests as you suggested.

There's nothing in the toplevel to support feature tests that 
enable/disable modules, unfortunately.  It's been done in a very ad-hoc 
way so far, perhaps you can just use "case $target in" (or is it "case 
$host in"? would it be possible to cross-compile from Solaris 10 to 
Solaris 11 using Sun tools?).

Paolo

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Paolo,

> On 06/27/2011 01:32 PM, Rainer Orth wrote:
>> 	Support libmudflap on Solaris (PR libmudflap/38738)
>>          http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
>>
>> This needs the mudflap maintainer.
>
> Build changes are okay, the rest is pretty obvious.
>
> For pass-stratcliff I'd rather use autoconf tests as you suggested.

will do in the next step when dealing with remaining libmudflap failures
on Solaris.

> There's nothing in the toplevel to support feature tests that
> enable/disable modules, unfortunately.  It's been done in a very ad-hoc way
> so far, perhaps you can just use "case $target in" (or is it "case $host
> in"? would it be possible to cross-compile from Solaris 10 to Solaris 11
> using Sun tools?).

It would, but I'd rather move this out of toplevel completely, having
the modules enable/disable themselves depending on either static
configuration or configure test outcome.  I think Joseph had ideas for
something like this.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University