On Thu, Oct 7, 2021 at 10:28 PM Lennart Sorensen
wrote:
> On Wed, Oct 06, 2021 at 02:08:49PM -0400, Camm Maguire wrote:
>
> I also get the impression in my searching for stuff about this problem,
> that 3/4 of the things I find about wanting to do this are gcl related.
> I guess it may be the
On Wed, Oct 06, 2021 at 02:08:49PM -0400, Camm Maguire wrote:
> Greetings, and thanks for your reply
>
> On Tue, 5 Oct 2021 15:01:59 -0400, Len Sorensen wrote:
>
> >>From what I could find, some programs allocate their own stack early in
> >execution and can hence put it where they want which I
Greetings, and thanks for your reply
On Tue, 5 Oct 2021 15:01:59 -0400, Len Sorensen wrote:
>>From what I could find, some programs allocate their own stack early in
>execution and can hence put it where they want which I guess would free
>up some known address space range. Potentially. With
On Tue, Oct 05, 2021 at 03:23:53PM -0400, Camm Maguire wrote:
>...
> Fair enough, but *Debian* ships a given compiled kernel fixing this
> parameter, no? That is the target for the distribution and
> apps/packages.
Most x86 users use our kernel, but not on arm.
On x86 nearly all hardware
On Tue, Oct 5, 2021 at 7:37 PM Camm Maguire wrote:
>
> Greetings, and thank you so much for your very detailed, clear, and
> comprehensive reply!
>
> PER_LINUX_32GB and/or a userspace interface to set the address space
> layout would be nice, but my chief concern is that whatever the kernel
>
On Tue, Oct 05, 2021 at 04:17:51PM -0400, Jeffrey Walton wrote:
> On Tue, Oct 5, 2021 at 4:00 PM Lennart Sorensen
> wrote:
> >
> > ...
> > This fixnum idea in gcl is broken. It must go away. Pointers are for
> > addresses and nothing else.
>
> +1. Tagged pointers caused a lot of problems
On Tue, Oct 5, 2021 at 4:00 PM Lennart Sorensen
wrote:
>
> ...
> This fixnum idea in gcl is broken. It must go away. Pointers are for
> addresses and nothing else.
+1. Tagged pointers caused a lot of problems porting some packages to
Aarch64. Tagged pointers were blocking a number of web
On Tue, Oct 05, 2021 at 03:23:53PM -0400, Camm Maguire wrote:
> Greetings!
>
> Fair enough, but *Debian* ships a given compiled kernel fixing this
> parameter, no? That is the target for the distribution and
> apps/packages. Users compiling their own kernel can expect
> incompatibilities.
Greetings!
Fair enough, but *Debian* ships a given compiled kernel fixing this
parameter, no? That is the target for the distribution and
apps/packages. Users compiling their own kernel can expect
incompatibilities.
Take care,
Adrian Bunk writes:
> On Tue, Oct 05, 2021 at 01:37:49PM -0400,
On Tue, Oct 05, 2021 at 01:37:49PM -0400, Camm Maguire wrote:
>...
> To me it seems that the 64bit kernel, if it
> offers a compatibility mode, should match whatever the contemporaneous
> 32bit kernel behavior is, making this a bug in the compatibility mode.
>...
You are expecting compatibility
On Tue, Oct 05, 2021 at 01:37:49PM -0400, Camm Maguire wrote:
> Greetings, and thank you so much for your very detailed, clear, and
> comprehensive reply!
>
> PER_LINUX_32GB and/or a userspace interface to set the address space
> layout would be nice, but my chief concern is that whatever the
Greetings, and thank you so much for your very detailed, clear, and
comprehensive reply!
PER_LINUX_32GB and/or a userspace interface to set the address space
layout would be nice, but my chief concern is that whatever the kernel
provides to userspace be the same on all machines purporting to be
On Mon, Oct 4, 2021 at 7:38 PM Camm Maguire wrote:
>
> Greetings! There seems to be a subarchitecture within the current 32bit
> Debian arm universes and buildds. armv8 processors will leave the C
> stack start at 0x even when personality ADDR_LIMIT_3GB is set,
> whereas on armv7 the
13 matches
Mail list logo
