* H. Peter Anvin:
> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>> Why is the ia32 compatiblity kernel interface used?
>
> Because there is no way in hell we're designing in a second
> compatibility ABI in the kernel (and it has to be a compatibility ABI,
> because of the pointer size difference
Hi all,
I'm trying to build GCC (r170071) on powerpc-apple-darwin8.11.0 (a G4
Mac Mini with OS X 10.4.11). I built and installed gmp-5.0.1,
mpc-0.8.2 and mpfr-3.0.0, then ran
../gcc/configure --enable-languages=c,c++
make bootstrap
This failed with:
libtool: link: /Users/useruser/GCC/build/./gcc
On Feb 13, 2011, at 1:01 AM, Csaba Raduly wrote:
Hi all,
I'm trying to build GCC (r170071) on powerpc-apple-darwin8.11.0 (a G4
Mac Mini with OS X 10.4.11). I built and installed gmp-5.0.1,
mpc-0.8.2 and mpfr-3.0.0, then ran
../gcc/configure --enable-languages=c,c++
make bootstrap
tough to s
On Sun, Feb 13, 2011 at 2:34 AM, sa...@hederstierna.com
wrote:
> Hi
>
> I would like to have some advice regarding static code analysis and GCC.
> I've just reviewed several tools like Klocwork, Coverity, CodeSonar and
> PolySpace.
> These tools offer alot of features and all tools seems to find
On Feb 13, 2011, at 1:16 AM, Justin Mattock wrote:
On Feb 13, 2011, at 1:01 AM, Csaba Raduly wrote:
Hi all,
I'm trying to build GCC (r170071) on powerpc-apple-darwin8.11.0 (a G4
Mac Mini with OS X 10.4.11). I built and installed gmp-5.0.1,
mpc-0.8.2 and mpfr-3.0.0, then ran
../gcc/configure
On Sat, Feb 12, 2011 at 9:47 PM, Matt Thomas wrote:
>
> On Feb 12, 2011, at 7:02 PM, Andrew Pinski wrote:
>
>> On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin wrote:
>>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
Why is the ia32 compatiblity kernel interface used?
>>>
>>> Because there is
On Sun, Feb 13, 2011 at 12:48 AM, Florian Weimer wrote:
> * H. Peter Anvin:
>
>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>>> Why is the ia32 compatiblity kernel interface used?
>>
>> Because there is no way in hell we're designing in a second
>> compatibility ABI in the kernel (and it has to
* H. J. Lu:
>> Actually, I'm wondering if you can do the translation in user space.
>> There already are 32-on-64 implementations in existence, without
>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>
> Please check out the x32 kernel source and provide feedback.
I still don'
On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> Actually, I'm wondering if you can do the translation in user space.
>>> There already are 32-on-64 implementations in existence, without
>>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>
>> Please che
* H. J. Lu:
> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
>> * H. J. Lu:
>>
Actually, I'm wondering if you can do the translation in user space.
There already are 32-on-64 implementations in existence, without
kernel changes (recent Hotspot, LuaJIT, and probably some mor
On Sun, Feb 13, 2011 at 7:21 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
>>> * H. J. Lu:
>>>
> Actually, I'm wondering if you can do the translation in user space.
> There already are 32-on-64 implementations in existence, without
>>
On Sun, 13 Feb 2011, Florian Weimer wrote:
> >> Actually, I'm wondering if you can do the translation in user space.
> >> There already are 32-on-64 implementations in existence, without
> >> kernel changes (recent Hotspot, LuaJIT, and probably some more).
> >
> > Please check out the x32 kernel s
On Sun, Feb 13, 2011 at 7:43 AM, Maciej W. Rozycki wrote:
> On Sun, 13 Feb 2011, Florian Weimer wrote:
>
>> >> Actually, I'm wondering if you can do the translation in user space.
>> >> There already are 32-on-64 implementations in existence, without
>> >> kernel changes (recent Hotspot, LuaJIT, a
On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
> > * H. J. Lu:
> >
> >>> Actually, I'm wondering if you can do the translation in user space.
> >>> There already are 32-on-64 implementations in existence, without
> >>> kernel chang
2011/2/13 Petr Baudis :
> On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
>> > * H. J. Lu:
>> >
>> >>> Actually, I'm wondering if you can do the translation in user space.
>> >>> There already are 32-on-64 implementations in existe
On 13 February 2011 09:01, Csaba Raduly wrote:
>
> Any idea what could be the problem and how to fix it? Should I just
> run a simple "make"?
Questions about using or building gcc should be sent to
gcc-h...@gcc.gnu.org, not this list, please follow up there instead,
thanks.
I don't know if it wil
On Sun, 13 Feb 2011, Petr Baudis wrote:
> I think it would be great if you could add some text like this plus some
> rationale (AIUI, this is geared mainly at new Atoms and other x86_64
> embedded platforms) to the document.
>
> (BTW, it is not really convincing to me that such a niche is worth a
On Sun, Feb 13, 2011 at 05:27:37PM +, Jonathan Wakely wrote:
> On 13 February 2011 09:01, Csaba Raduly wrote:
> >
> > Any idea what could be the problem and how to fix it? Should I just
> > run a simple "make"?
>
> Questions about using or building gcc should be sent to
> gcc-h...@gcc.gnu.org,
Status
==
Trunk is in Stage 4, for regression fixes and documentation fixes.
The numbers of regressions have continued to go down since the
previous report, but more work is still needed especially on the P1
regressions. User-visible improvements relative to 4.5 should also be
documented in
Snapshot gcc-4.3-20110213 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110213/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
> Hi,
>
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
Really? I haven't seen this being posted for review yet ;-)
The basic concept looks en
On Sun, Feb 13, 2011 at 12:10 PM, Arnd Bergmann wrote:
> On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
>> Hi,
>>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is close to be finalized.
>
> Really? I haven't seen
On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>>
>>> 1. Kernel interface with syscall is close to be finalized.
>>
I don't think calling it "finalized" is accurate... it is more
accurately described as "prototyped".
>> Really? I haven't seen this being posted for review yet ;-)
>>
>> The basic concept
On Sun, Feb 13, 2011 at 1:16 PM, H. Peter Anvin wrote:
> On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>> The basic concept looks entirely reasonable to me, but I'm
>>> curious what drove the decision to start out with the x86_64
>>> system calls instead of the generic ones.
>>>
>>> Since tile was merge
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but
On 02/13/2011 01:28 PM, H.J. Lu wrote:
>
> That is is currently implemented on hjl/x32 branch.
>
> I also added
>
> __NR_sigaction
> __NR_sigpending
> __NR_sigprocmask
> __NR_sigsuspend
>
> to help the Bionic C library.
>
That seems a little redundant... even on the i386 front we want people
On Sun, Feb 13, 2011 at 2:03 PM, H. Peter Anvin wrote:
> On 02/13/2011 01:28 PM, H.J. Lu wrote:
>>
>> That is is currently implemented on hjl/x32 branch.
>>
>> I also added
>>
>> __NR_sigaction
>> __NR_sigpending
>> __NR_sigprocmask
>> __NR_sigsuspend
>>
>> to help the Bionic C library.
>>
>
> Tha
On 02/13/2011 01:16 PM, H. Peter Anvin wrote:
>
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're plan
On Sunday 13 February 2011, H. Peter Anvin wrote:
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're pla
On 02/13/2011 02:28 PM, Arnd Bergmann wrote:
> On Sunday 13 February 2011, H. Peter Anvin wrote:
>> The actual idea is to use the i386 compat ABI for memory layout, but
>> with a 64-bit register convention. That means that system calls that
>> don't make references to memory structures can simply
On 02/13/2011 01:31 AM, Eric Botcazou wrote:
>> I figured if I knew what was needed before opening the bug it would cut
>> down on the need-info requests. Thanks.
>
> The instructions are available on the http://gcc.gnu.org/bugs/ page.
>
Thank you Eric,
I've tried to include everyt
On Sunday 13 February 2011, H. Peter Anvin wrote:
> We prototyped using the int $0x80 system call entry point. However,
> there are two disadvantages:
>
> a. the int $0x80 instruction is much slower than syscall. An actual
>i386 process can use the syscall instruction which is disambiguated
On Sun, Feb 13, 2011 at 2:57 PM, Arnd Bergmann wrote:
>
>> The cost of an entire different ABI layer (supporting a new memory layout)
>> would be enormous, a.k.a. "not worth it", which is why the memory layout
>> of kernel objects needs to be compatible with i386.
>
> Right, this makes sense, you
> a. the int $0x80 instruction is much slower than syscall. An actual
>i386 process can use the syscall instruction which is disambiguated
>by the CPU based on mode, but an x32 process is in the same CPU mode
>as a normal 64-bit process.
So set a flag, whoopee
> b. 64-bit arguments h
On Sun, Feb 13, 2011 at 3:39 PM, Alan Cox wrote:
>> a. the int $0x80 instruction is much slower than syscall. An actual
>> i386 process can use the syscall instruction which is disambiguated
>> by the CPU based on mode, but an x32 process is in the same CPU mode
>> as a normal 64-bit pro
On 02/13/2011 01:33 PM, Alan Cox wrote:
Who actually needs this new extra API - whats the justification for
everyone having more crud dumping their kernels, more syscall paths
(which are one of the most security critical areas) and the like.
What are the benchmark numbers to justify this versus
On 02/13/2011 03:39 PM, Alan Cox wrote:
a. the int $0x80 instruction is much slower than syscall. An actual
i386 process can use the syscall instruction which is disambiguated
by the CPU based on mode, but an x32 process is in the same CPU mode
as a normal 64-bit process.
So set a
37 matches
Mail list logo
