On Wed, Jan 28, 2009 at 1:40 AM, Andi Kleen wrote:
> On Wed, Jan 28, 2009 at 10:21:16AM +0100, Paolo Bonzini wrote:
>> Andi Kleen wrote:
>> > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
>> >>> He'll get much better code by putting the program into a -fPIC .so,
>> >>> loading it
On Wed, Jan 28, 2009 at 10:21:16AM +0100, Paolo Bonzini wrote:
> Andi Kleen wrote:
> > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
> >>> He'll get much better code by putting the program into a -fPIC .so,
> >>> loading it from a small stub and then unmap the stub.
> >>> large mod
Andi Kleen wrote:
> On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
>>> He'll get much better code by putting the program into a -fPIC .so,
>>> loading it from a small stub and then unmap the stub.
>>> large model generates really very bad code because all jumps
>>> will be indirect.
On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
>
> > He'll get much better code by putting the program into a -fPIC .so,
> > loading it from a small stub and then unmap the stub.
> > large model generates really very bad code because all jumps
> > will be indirect.
>
> Is it also
> He'll get much better code by putting the program into a -fPIC .so,
> loading it from a small stub and then unmap the stub.
> large model generates really very bad code because all jumps
> will be indirect.
Is it also true with -fpie?
Paolo
On Tue, Jan 27, 2009 at 09:33:17AM -0800, Steve Ellcey wrote:
> On Tue, 2009-01-27 at 12:31 +0100, Andi Kleen wrote:
> > Steve Ellcey writes:
> >
> > > because the crt files can't handle the large code model if they aren't
> > > compiled with this option.
> >
> > My understanding is that this wou
On Tue, Jan 27, 2009 at 9:42 AM, Steve Ellcey wrote:
> On Tue, 2009-01-27 at 09:39 -0800, H.J. Lu wrote:
>
>> Hi Steve,
>>
>> Can you open a bug report with a testcase?
>>
>> Thanks.
>
> I have submitted a bug report about the GCC bugs I ran into:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
On Tue, 2009-01-27 at 09:39 -0800, H.J. Lu wrote:
> Hi Steve,
>
> Can you open a bug report with a testcase?
>
> Thanks.
I have submitted a bug report about the GCC bugs I ran into:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988
Or do you mean a bug report about crtstuff.c not being compil
On Tue, Jan 27, 2009 at 9:33 AM, Steve Ellcey wrote:
> On Tue, 2009-01-27 at 12:31 +0100, Andi Kleen wrote:
>> Steve Ellcey writes:
>>
>> > because the crt files can't handle the large code model if they aren't
>> > compiled with this option.
>>
>> My understanding is that this would likely break
On Tue, 2009-01-27 at 12:31 +0100, Andi Kleen wrote:
> Steve Ellcey writes:
>
> > because the crt files can't handle the large code model if they aren't
> > compiled with this option.
>
> My understanding is that this would likely break old linkers which
> didn't do all large model relocations co
Steve Ellcey writes:
> The first one is: would it be reasonable to compile crt files with
> -mcmodel=large by default on the x86-64 linux platform? Currently the
> crt files are not compiled with this option and that makes it impossible
> to compile a program where the text segment is above 4GB
I have a user who is trying to use the large code model on x86-64 Linux
(-mcmodel=large) and is running into some trouble and I have a couple of
questions for the x86-64 experts/maintainers.
The first one is: would it be reasonable to compile crt files with
-mcmodel=large by default on the x86-64
12 matches
Mail list logo
