Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

2019-08-08 Thread Ben Hutchings
On Fri, 2019-08-09 at 00:28 +0200, Aurelien Jarno wrote: > On 2019-08-08 22:23, Ben Hutchings wrote: [...] > > 1a. Require 32-bit build environments to be multiarch with the > > related 64-bit architecture also enabled. > > Indeed, but that looks like the first step. From there do you think >

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

2019-08-08 Thread Aurelien Jarno
On 2019-08-08 23:57, John Paul Adrian Glaubitz wrote: > Hi! > > On 8/8/19 10:38 PM, Aurelien Jarno wrote: > > Any comments, ideas, or help here? > I'm by no means a GHC nor Haskell expert, but I think it should be generally > feasible to add native code generation support in GHC for all architectu

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

2019-08-08 Thread Aurelien Jarno
On 2019-08-08 22:23, Ben Hutchings wrote: > On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote: > [...] > > 1) Build a 64-bit compiler targeting the 32-bit corresponding > >architecture and install it in the 32-bit chroot with the other > >64-bit dependencies. This is still a kind of c

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

2019-08-08 Thread John Paul Adrian Glaubitz
Hi! On 8/8/19 10:38 PM, Aurelien Jarno wrote: > Any comments, ideas, or help here? I'm by no means a GHC nor Haskell expert, but I think it should be generally feasible to add native code generation support in GHC for all architectures which are supported by LLVM. According to a bug report I saw

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

2019-08-08 Thread Ben Hutchings
On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote: [...] > 1) Build a 64-bit compiler targeting the 32-bit corresponding >architecture and install it in the 32-bit chroot with the other >64-bit dependencies. This is still a kind of cross-compiler, but the >rest of the build is unc

Bypassing the 2/3/4GB virtual memory space on 32-bit ports

2019-08-08 Thread Aurelien Jarno
[ debian-arm is Cced: as armel and armhf might be impacted in the future] [ debian-devel is Cced: as i386 might be impacted in the future] [ debian-release is Cced: as the release has to agree with the solution] Hi all, 32-bit processes are able to address at maximum 4GB of memory (2^32), a

DTB for Kernel 4.19 nicht funktioniert!

2019-08-08 Thread Danil Nedbailov
Sehr geehrte Damen und Herren, Gestern habe ich Debian 9.9 in Buffalo LinkStation Mini LS-WSGL installiert. Mit dem Kernel 4.9 Kontrolle für LEDs funktioniert. Nach dem Update für Kernel to 4.19 und jetzt LEDs funktioniert nicht. DTB datai von 4.19 ist kleiner. Mit freundlichen Grüßen Danil Nedba