On 06/09/2011 09:42 AM, Rainer Orth wrote:
> Indeed, that did the trick. The following revised patch has been
> bootstrapped without regressions on i386-pc-solaris2.10. I've already
> got build, Darwin and Mingw approval and can commit the osf and solaris
> parts on my own. If the C parts are ok
On Thu, 9 Jun 2011, Rainer Orth wrote:
> Indeed, that did the trick. The following revised patch has been
> bootstrapped without regressions on i386-pc-solaris2.10. I've already
> got build, Darwin and Mingw approval and can commit the osf and solaris
> parts on my own. If the C parts are ok no
"Joseph S. Myers" writes:
> On Tue, 7 Jun 2011, Rainer Orth wrote:
>
>> > So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if
>> > -fbuilding-libgcc.
>>
>> I can give it a try if I can figure out how to define -fbuilding-libgcc
>> via the option handling machinery. I just
On Tue, 7 Jun 2011, Rainer Orth wrote:
> > So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if
> > -fbuilding-libgcc.
>
> I can give it a try if I can figure out how to define -fbuilding-libgcc
> via the option handling machinery. I just want to avoid having to
That should
On 06/07/2011 05:30 PM, Rainer Orth wrote:
> So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if
> -fbuilding-libgcc.
I can give it a try if I can figure out how to define -fbuilding-libgcc
via the option handling machinery. I just want to avoid having to
implement too ma
"Joseph S. Myers" writes:
> On Mon, 6 Jun 2011, Rainer Orth wrote:
>
>> Paolo Bonzini writes:
>>
>> >> * Except for Darwin, the code uses TRAMPOLINE_SIZE. This only exists in
>> >>the backend headers. While it could be duplicated somewhere in the
>> >>libgcc configury, I'd rather prop
On Mon, 6 Jun 2011, Rainer Orth wrote:
> Paolo Bonzini writes:
>
> >> * Except for Darwin, the code uses TRAMPOLINE_SIZE. This only exists in
> >>the backend headers. While it could be duplicated somewhere in the
> >>libgcc configury, I'd rather propose that gcc define
> >>__TRAMPO
"Joseph S. Myers" writes:
> On Tue, 31 May 2011, Paolo Bonzini wrote:
>
>> > I'd thought about it, but refrained since HAVE_ENABLE_EXECUTE_STACK
>> > affects only three cpus. Currently, our documentation of libgcc
>> > configury and macros used is close to non-existant. That's probably for
>> >
On Tue, 31 May 2011, Paolo Bonzini wrote:
> > I'd thought about it, but refrained since HAVE_ENABLE_EXECUTE_STACK
> > affects only three cpus. Currently, our documentation of libgcc
> > configury and macros used is close to non-existant. That's probably for
> > someone who has implemented this s
On 06/06/2011 11:17 AM, Rainer Orth wrote:
* Instead of __FreeBSD__, one could use HAVE_SYSCTLBYNAME instead, but
that would need a new libgcc config.h header. In addition, we might
have to check for kern.stackprot to make sure the code really works.
* Similarly, instead of testing __sun_
Paolo Bonzini writes:
>> * Except for Darwin, the code uses TRAMPOLINE_SIZE. This only exists in
>>the backend headers. While it could be duplicated somewhere in the
>>libgcc configury, I'd rather propose that gcc define
>>__TRAMPOLINE_SIZE__ (in gcc/c-family/c-cppbuiltin.c (c_cpp_b
Rainer Orth writes:
> * FreeBSD uses the unmodified address passed to __enable_execute_stack
> to call mprocted, while all others round both address and size to a
> pagesize boundary. I cannot imagine that FreeBSD supports
> byte-granularity mprotect, so this seems an oversight.
Apparentl
On Fri, 3 Jun 2011, Rainer Orth wrote:
> * FreeBSD uses the unmodified address passed to __enable_execute_stack
> to call mprocted, while all others round both address and size to a
> pagesize boundary. I cannot imagine that FreeBSD supports
> byte-granularity mprotect, so this seems an over
On 06/03/2011 05:45 PM, Rainer Orth wrote:
Paolo Bonzini writes:
>> Seems like a plan, but I didn't go in this direction since I couldn't
>> test anything like this.
>
> As long as you test the general configury on 1-2 platforms, it's not any
> less tested than what you have now.
Unfortu
Paolo Bonzini writes:
>> Seems like a plan, but I didn't go in this direction since I couldn't
>> test anything like this.
>
> As long as you test the general configury on 1-2 platforms, it's not any
> less tested than what you have now.
Unfortunately, that's not true: my original patch just mov
On May 30, 2011, at 8:59 AM, Rainer Orth wrote:
> This is my hopefully last patch for toplevel libgcc moves: it moves
> ENABLE_EXECUTE_STACK to $target-lib.h headers in libgcc/config.
> Ok for mainline after a week if no problems occur in testing on the
> other targets?
Ok for the darwin bits.
Seems like a plan, but I didn't go in this direction since I couldn't
test anything like this.
As long as you test the general configury on 1-2 platforms, it's not any
less tested than what you have now.
The various __enable_execute_stack
implementations differ in minor ways that would have
Paolo Bonzini writes:
>> The new libgcc/config/$target-lib.h headers are added to libgcc_tm_file
>> in gcc/config.gcc. I'd rather add them to libgcc/config.host instead so
>> the information is kept local to libgcc.
>
> Did you have any problems doing so?
There weren't any provisions in libgcc/
On 05/30/2011 05:59 PM, Rainer Orth wrote:
This is my hopefully last patch for toplevel libgcc moves: it moves
ENABLE_EXECUTE_STACK to $target-lib.h headers in libgcc/config. Since
gcc/config/sol2.h is only used on Solaris targets anymore and Solaris 8
is the minimal supported version, I've remo
Jason Thorpe"
, "Krister Walfridsson" ,
"Uros Bizjak" , "Richard Henderson" , "Eric
Botcazou"
Sent: Monday, May 30, 2011 5:59:10 PM
Subject: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc
This is my hopefully last patch for toplevel libgcc moves:
This is my hopefully last patch for toplevel libgcc moves: it moves
ENABLE_EXECUTE_STACK to $target-lib.h headers in libgcc/config. Since
gcc/config/sol2.h is only used on Solaris targets anymore and Solaris 8
is the minimal supported version, I've removed both a Solaris 2.6
workaround and include
21 matches
Mail list logo
