On Fri, Jan 14, 2011 at 3:46 PM, H.J. Lu wrote:
> On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu wrote:
>> On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu wrote:
>>> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin wrote:
On 12/30/2010 01:08 PM, Robert Millan wrote:
> Hi folks,
>
> I had thi
On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu wrote:
>> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin wrote:
>>> On 12/30/2010 01:08 PM, Robert Millan wrote:
Hi folks,
I had this unsubmitted patch in my local filesystem. It makes Lin
On Wed, Jan 5, 2011 at 11:52 AM, Jonathan Wakely wrote:
> On 30 December 2010 18:23, H.J. Lu wrote:
>>
>> This patch adds 32bit x86-64 support to binutils. Support in compiler,
>> library and OS is required to use it. It can be used to implement the
>> new 32bit OS for x86-64. Any comments?
>
>
On 30 December 2010 18:23, H.J. Lu wrote:
>
> This patch adds 32bit x86-64 support to binutils. Support in compiler,
> library and OS is required to use it. It can be used to implement the
> new 32bit OS for x86-64. Any comments?
I have a small comment on the changes to the c-i386.texi docs:
di
>>> On 05.01.11 at 09:01, "H. Peter Anvin" wrote:
> On 01/04/2011 11:46 PM, Jan Beulich wrote:
Oh god, please, no.
I have to say I'm highly questioning to Jan's statement in the first
place. Crossing 32- and 64-bit ELF like that sounds like a kernel
security hole wai
On 01/04/2011 11:46 PM, Jan Beulich wrote:
>>>
>>> Oh god, please, no.
>>>
>>> I have to say I'm highly questioning to Jan's statement in the first
>>> place. Crossing 32- and 64-bit ELF like that sounds like a kernel
>>> security hole waiting to happen.
>
> A particular OS/kernel has the freedom
>>> On 04.01.11 at 21:02, Jakub Jelinek wrote:
> On Tue, Jan 04, 2011 at 10:35:42AM -0800, H. Peter Anvin wrote:
>> On 01/04/2011 09:56 AM, H.J. Lu wrote:
>> >>
>> >> I think it is a gross misconception to tie the ABI to the ELF class of
>> >> an object. Specifying the ABI should imo be done via e
On Tue, Jan 04, 2011 at 10:35:42AM -0800, H. Peter Anvin wrote:
> On 01/04/2011 09:56 AM, H.J. Lu wrote:
> >>
> >> I think it is a gross misconception to tie the ABI to the ELF class of
> >> an object. Specifying the ABI should imo be done via e_flags or
> >> one of the unused bytes of e_ident, and
On 01/04/2011 09:56 AM, H.J. Lu wrote:
>>
>> I think it is a gross misconception to tie the ABI to the ELF class of
>> an object. Specifying the ABI should imo be done via e_flags or
>> one of the unused bytes of e_ident, and in all reality the ELF class
>> should *only* affect the file layout (and
On Mon, Jan 3, 2011 at 2:40 AM, Jan Beulich wrote:
On 30.12.10 at 21:02, "H.J. Lu" wrote:
>>
>> Here is the ILP32 psABI:
>>
>> http://www.kernel.org/pub/linux/devel/binutils/ilp32/
>>
>
> I think it is a gross misconception to tie the ABI to the ELF class of
> an object. Specifying the ABI s
>>> On 30.12.10 at 21:02, "H.J. Lu" wrote:
>
> Here is the ILP32 psABI:
>
> http://www.kernel.org/pub/linux/devel/binutils/ilp32/
>
I think it is a gross misconception to tie the ABI to the ELF class of
an object. Specifying the ABI should imo be done via e_flags or
one of the unused bytes of
On 12/31/2010 02:03 AM, Jakub Jelinek wrote:
> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
Would be nice if LFS would be mandatory on the new ABI, thus
off_t being 64bits.
>>>
>>> And avoid ambiguous cases that x86-6
On Fri, Dec 31, 2010 at 8:50 AM, H.J. Lu wrote:
> On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek wrote:
>> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>>> >>
>>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>>
On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek wrote:
> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>> >>
>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>> >> off_t being 64bits.
>> >
>> > And avoid ambiguous c
On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin wrote:
>> On 12/30/2010 01:08 PM, Robert Millan wrote:
>>> Hi folks,
>>>
>>> I had this unsubmitted patch in my local filesystem. It makes Linux
>>> detect ELF32 AMD64 binaries and sets a flag to re
On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek wrote:
> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>> >>
>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>> >> off_t being 64bits.
>> >
>> > And avoid ambiguous c
On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
> >>
> >> Would be nice if LFS would be mandatory on the new ABI, thus
> >> off_t being 64bits.
> >
> > And avoid ambiguous cases that x86-64 ABI has, e.g. whether
> > caller or callee is
On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin wrote:
> On 12/30/2010 01:08 PM, Robert Millan wrote:
>> Hi folks,
>>
>> I had this unsubmitted patch in my local filesystem. It makes Linux
>> detect ELF32 AMD64 binaries and sets a flag to restrict them to
>> 32-bit address space.
>>
>> It's not r
On 12/30/2010 01:08 PM, Robert Millan wrote:
> Hi folks,
>
> I had this unsubmitted patch in my local filesystem. It makes Linux
> detect ELF32 AMD64 binaries and sets a flag to restrict them to
> 32-bit address space.
>
> It's not rocket science but can save you some work in case you
> haven't
On Thu, Dec 30, 2010 at 4:25 PM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
> wrote:
>> On Thu, 30 Dec 2010, H. Peter Anvin wrote:
>>
>>> On 12/30/2010 02:21 PM, Robert Millan wrote:
>>> > 2010/12/30 Richard Guenther :
>>> >> Would be nice if LFS would be mandatory on the n
On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H. Peter Anvin wrote:
>
>> On 12/30/2010 02:21 PM, Robert Millan wrote:
>> > 2010/12/30 Richard Guenther :
>> >> Would be nice if LFS would be mandatory on the new ABI, thus
>> >> off_t being 64bits.
>> >
>> > Please do
On Thu, 30 Dec 2010, H. Peter Anvin wrote:
> On 12/30/2010 02:21 PM, Robert Millan wrote:
> > 2010/12/30 Richard Guenther :
> >> Would be nice if LFS would be mandatory on the new ABI, thus
> >> off_t being 64bits.
> >
> > Please do also consider time_t.
> >
>
> Changing the kernel-facing time_
On 12/30/2010 02:21 PM, Robert Millan wrote:
> 2010/12/30 Richard Guenther :
>> Would be nice if LFS would be mandatory on the new ABI, thus
>> off_t being 64bits.
>
> Please do also consider time_t.
>
Changing the kernel-facing time_t might completely wreck the reuse of
the i386 kernel ABI; I'm
On 12/30/2010 02:18 PM, Robert Millan wrote:
> 2010/12/30 H.J. Lu :
>> I also have a patch for gcc 4.4 which works on simple codes.
>>
>> H.J.
>> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
>>> We do have a slightly more extensive patch already implemented.
>
> Could you make those pat
On Thu, Dec 30, 2010 at 2:18 PM, Robert Millan wrote:
> 2010/12/30 H.J. Lu :
>> I also have a patch for gcc 4.4 which works on simple codes.
>>
>> H.J.
>> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
>>> We do have a slightly more extensive patch already implemented.
>
> Could you make
2010/12/30 Richard Guenther :
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
Please do also consider time_t.
--
Robert Millan
2010/12/30 H.J. Lu :
> I also have a patch for gcc 4.4 which works on simple codes.
>
> H.J.
> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
>> We do have a slightly more extensive patch already implemented.
Could you make those patches available somewhere? It'd be
interesting to play w
On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>>
>> Would be nice if LFS would be mandatory on the new ABI, thus
>> off_t being 64bits.
>
> And avoid ambiguous cases that x86-64 ABI has, e.g. whether
> caller or callee is responsible for sign/zero extension of arguments, to
> avoid the need to sign
On 12/30/2010 12:39 PM, David Daney wrote:
>
> Really I don't care one way or the other. The necessity of syscall
> wrappers is actually probably beneficial to me. It will create a
> greater future employment demand for people with the necessary skills to
> write them.
>
Or perhaps automatic g
I also have a patch for gcc 4.4 which works on simple codes.
H.J.
On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
> We do have a slightly more extensive patch already implemented.
>
> "Robert Millan" wrote:
>
>>Hi folks,
>>
>>I had this unsubmitted patch in my local filesystem. It makes
We do have a slightly more extensive patch already implemented.
"Robert Millan" wrote:
>Hi folks,
>
>I had this unsubmitted patch in my local filesystem. It makes Linux
>detect ELF32 AMD64 binaries and sets a flag to restrict them to
>32-bit address space.
>
>It's not rocket science but can sav
I believe it covers all cases *relevant for this particular situation* (unlike,
say, MIPS) and that any deviation is a bug which can and should be fixed.
"David Daney" wrote:
>On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>
>>> My suggestion: Sin
Hi folks,
I had this unsubmitted patch in my local filesystem. It makes Linux
detect ELF32 AMD64 binaries and sets a flag to restrict them to
32-bit address space.
It's not rocket science but can save you some work in case you
haven't implemented this already.
Best regards
--
Robert Millan
di
On 12/30/2010 12:28 PM, H.J. Lu wrote:
On Thu, Dec 30, 2010 at 12:27 PM, David Daney wrote:
On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
On 12/30/2010 11:34 AM, David Daney wrote:
My suggestion: Since people already spend a great deal of effort
maintaining the existing i386 compatible Lin
On Thu, 30 Dec 2010, Richard Guenther wrote:
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
That's certainly abstractly better (and something BSDs do better than
GNU/Linux). I expect you'd run into a few complications actually making a
32-bit glibc port li
On Thu, Dec 30, 2010 at 12:27 PM, David Daney wrote:
> On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>>
>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>
>>> My suggestion: Since people already spend a great deal of effort
>>> maintaining the existing i386 compatible Linux syscall infrastructure,
On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
On 12/30/2010 11:34 AM, David Daney wrote:
My suggestion: Since people already spend a great deal of effort
maintaining the existing i386 compatible Linux syscall infrastructure,
make your new 32-bit x86-64 Linux syscall ABI identical to the existi
On Thu, Dec 30, 2010 at 12:02 PM, H.J. Lu wrote:
>
> Here is the ILP32 psABI:
>
> http://www.kernel.org/pub/linux/devel/binutils/ilp32/
>
I put my x86-64 psABI changes at:
http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary
Please send me patches to improve the ILP32 psABI.
On 12/30/2010 11:34 AM, David Daney wrote:
>
> My suggestion: Since people already spend a great deal of effort
> maintaining the existing i386 compatible Linux syscall infrastructure,
> make your new 32-bit x86-64 Linux syscall ABI identical to the existing
> i386 syscall ABI. This means that t
On 12/30/2010 11:53 AM, Richard Guenther wrote:
>
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
>
Yes, although that's a higher-order thing.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their beh
On Thu, Dec 30, 2010 at 11:40 AM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
> wrote:
>> On Thu, 30 Dec 2010, H.J. Lu wrote:
>>
>>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>>> wrote:
>>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> This p
On Thu, Dec 30, 2010 at 08:53:32PM +0100, Richard Guenther wrote:
> > Syscalls sometimes need three different versions in the kernel; sometimes
> > the wrong version gets put in the n32 syscall table. Special syscall
> > wrappers are often needed in glibc; although for most purposes the glibc
> >
On Thu, Dec 30, 2010 at 8:30 PM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> wrote:
>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>> >
>> >> Hi,
>> >>
>> >> This patch adds 32bit x86-64 support to binutils. Support in compiler,
On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
>> wrote:
>> > On Thu, 30 Dec 2010, H.J. Lu wrote:
>> >
>> >> Hi,
>> >>
>> >> This patch adds 32bit x86-64 support to binutils. Support in compiler
On 12/30/2010 10:59 AM, H.J. Lu wrote:
On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
wrote:
On Thu, 30 Dec 2010, H.J. Lu wrote:
Hi,
This patch adds 32bit x86-64 support to binutils. Support in compiler,
library and OS is required to use it. It can be used to implement the
new 32bit OS
On Thu, 30 Dec 2010, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
> wrote:
> > On Thu, 30 Dec 2010, H.J. Lu wrote:
> >
> >> Hi,
> >>
> >> This patch adds 32bit x86-64 support to binutils. Support in compiler,
> >> library and OS is required to use it. It can be used to impl
On 12/30/2010 10:59 AM, H.J. Lu wrote:
>
>> (If you could arrange for the syscall ABI always to be the same as the
>> existing 64-bit ABI, rather than needing to handle three different syscall
>> ABIs in the kernel, that might be one solution, but it could have its own
>> complexities in ensuring
On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
wrote:
> On Thu, 30 Dec 2010, H.J. Lu wrote:
>
>> Hi,
>>
>> This patch adds 32bit x86-64 support to binutils. Support in compiler,
>> library and OS is required to use it. It can be used to implement the
>> new 32bit OS for x86-64. Any comments?
On Thu, 30 Dec 2010, H.J. Lu wrote:
> Hi,
>
> This patch adds 32bit x86-64 support to binutils. Support in compiler,
> library and OS is required to use it. It can be used to implement the
> new 32bit OS for x86-64. Any comments?
Do you have a public psABI document? I think the psABI at the E
49 matches
Mail list logo
