On Wed, 21 Nov 2018, Bernd Petrovitsch wrote:
> And yes, lots of stuff will not compile out of the box (especially if
> one uses a somewhat sane set of gcc options - not only -Wall -Wextra
> -Werror) but if one gets software to compile for i386 and x86_64,
> getting it to compile for x32 is a
On Wed, 21 Nov 2018, Bernd Petrovitsch wrote:
> And yes, lots of stuff will not compile out of the box (especially if
> one uses a somewhat sane set of gcc options - not only -Wall -Wextra
> -Werror) but if one gets software to compile for i386 and x86_64,
> getting it to compile for x32 is a
On Tue, Nov 20, 2018 at 4:35 PM Andy Lutomirski wrote:
>
> On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
> >
> > * Andy Lutomirski:
> >
> > > 5. Adjust the scripts so that we only have to wire up new syscalls
> > > once. They'll have a nr above 1024, and they'll have the same nr on
> >
On Tue, Nov 20, 2018 at 4:35 PM Andy Lutomirski wrote:
>
> On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
> >
> > * Andy Lutomirski:
> >
> > > 5. Adjust the scripts so that we only have to wire up new syscalls
> > > once. They'll have a nr above 1024, and they'll have the same nr on
> >
On Tue, Nov 20, 2018 at 1:25 AM Andy Lutomirski wrote:
>
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um, demented:
>
>
On Tue, Nov 20, 2018 at 1:25 AM Andy Lutomirski wrote:
>
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um, demented:
>
>
On 20/11/2018 08:33, Ingo Molnar wrote:
[...]
> 6. Is x32 even used in practice? I still think it was a mistake to add it
>and some significant distributions like Fedora are not enabling it.
x32 works as far as gcc/gas/ld is concerned (at least for compiling
non-trivial programs).
Finding a
On 20/11/2018 08:33, Ingo Molnar wrote:
[...]
> 6. Is x32 even used in practice? I still think it was a mistake to add it
>and some significant distributions like Fedora are not enabling it.
x32 works as far as gcc/gas/ld is concerned (at least for compiling
non-trivial programs).
Finding a
On Tue, Nov 20, 2018 at 07:23:09AM -0800, Andy Lutomirski wrote:
> On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
> >
> > * Andy Lutomirski:
> >
> > > 5. Adjust the scripts so that we only have to wire up new syscalls
> > > once. They'll have a nr above 1024, and they'll have the same nr
On Tue, Nov 20, 2018 at 07:23:09AM -0800, Andy Lutomirski wrote:
> On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
> >
> > * Andy Lutomirski:
> >
> > > 5. Adjust the scripts so that we only have to wire up new syscalls
> > > once. They'll have a nr above 1024, and they'll have the same nr
On Mon, Nov 19, 2018 at 04:22:49PM -0800, Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um,
On Mon, Nov 19, 2018 at 04:22:49PM -0800, Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um,
On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> > 5. Adjust the scripts so that we only have to wire up new syscalls
> > once. They'll have a nr above 1024, and they'll have the same nr on
> > all x86 variants.
>
> Is there a sufficiently sized gap on all other
On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> > 5. Adjust the scripts so that we only have to wire up new syscalls
> > once. They'll have a nr above 1024, and they'll have the same nr on
> > all x86 variants.
>
> Is there a sufficiently sized gap on all other
* Andy Lutomirski:
> 5. Adjust the scripts so that we only have to wire up new syscalls
> once. They'll have a nr above 1024, and they'll have the same nr on
> all x86 variants.
Is there a sufficiently sized gap on all other architectures as well?
The restriction to the x86 variants seems
* Andy Lutomirski:
> 5. Adjust the scripts so that we only have to wire up new syscalls
> once. They'll have a nr above 1024, and they'll have the same nr on
> all x86 variants.
Is there a sufficiently sized gap on all other architectures as well?
The restriction to the x86 variants seems
* Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um, demented:
>
> - The numbers don't match
* Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um, demented:
>
> - The numbers don't match
Hi all-
We currently have some giant turds in the way that syscalls are
numbered. We have the x86_32 table, which is totally sane other than
some legacy multiplexers. Then we have the x86_64 table, which is,
um, demented:
- The numbers don't match x86_32. I have no idea why.
- We use bit
Hi all-
We currently have some giant turds in the way that syscalls are
numbered. We have the x86_32 table, which is totally sane other than
some legacy multiplexers. Then we have the x86_64 table, which is,
um, demented:
- The numbers don't match x86_32. I have no idea why.
- We use bit
20 matches
Mail list logo
