| Message ID | bd66250ff262528199614f778a8323ced130a4db.1516221466.git.alistair.francis@xilinx.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 01/17/2018 05:39 PM, Alistair Francis wrote: > Since commit "linux-user: Tidy and enforce reserved_va initialization" > (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build > hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using > musl. > > To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match > to what it was before the problematic commit. > > Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > --- > > linux-user/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/linux-user/main.c b/linux-user/main.c > index 450eb3ce65..c7cc0a184e 100644 > --- a/linux-user/main.c > +++ b/linux-user/main.c > @@ -77,7 +77,7 @@ do { \ > (TARGET_LONG_BITS == 32 || defined(TARGET_ABI32)) > /* There are a number of places where we assign reserved_va to a variable > of type abi_ulong and expect it to fit. Avoid the last page. */ If this is only for MUSL shouldn't we think of smth like: ? #if defined(__GLIBC__) || defined(__UCLIBC__) > -# define MAX_RESERVED_VA (0xfffffffful & TARGET_PAGE_MASK) #else /* __MUSL__ */ > +# define MAX_RESERVED_VA (0x7ffffffful & TARGET_PAGE_MASK) #endif > # else > # define MAX_RESERVED_VA (1ul << TARGET_VIRT_ADDR_SPACE_BITS) > # endif >
On 01/17/2018 12:39 PM, Alistair Francis wrote: > Since commit "linux-user: Tidy and enforce reserved_va initialization" > (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build > hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using > musl. > > To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match > to what it was before the problematic commit. > > Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > --- I don't like this at all. You don't say why this hangs. What is the actual host, x86_64 or i686? r~
On Wed, Jan 17, 2018 at 4:57 PM, Richard Henderson <rth@twiddle.net> wrote: > On 01/17/2018 12:39 PM, Alistair Francis wrote: >> Since commit "linux-user: Tidy and enforce reserved_va initialization" >> (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build >> hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using >> musl. >> >> To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match >> to what it was before the problematic commit. >> >> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >> --- > > I don't like this at all. You don't say why this hangs. > What is the actual host, x86_64 or i686? The host is x86_64 and the guest is i686. I'm not sure why it hangs, I'll dig through and get the actual command Yocto is running when it hangs. Alistair > > > r~
On Wed, Jan 17, 2018 at 9:46 PM, Alistair Francis <alistair.francis@xilinx.com> wrote: > On Wed, Jan 17, 2018 at 4:57 PM, Richard Henderson <rth@twiddle.net> wrote: >> On 01/17/2018 12:39 PM, Alistair Francis wrote: >>> Since commit "linux-user: Tidy and enforce reserved_va initialization" >>> (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build >>> hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using >>> musl. >>> >>> To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match >>> to what it was before the problematic commit. >>> >>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >>> --- >> >> I don't like this at all. You don't say why this hangs. >> What is the actual host, x86_64 or i686? > > The host is x86_64 and the guest is i686. I'm not sure why it hangs, > I'll dig through and get the actual command Yocto is running when it > hangs. Ok, this is not going to be straightforward at all. The webkitgtk cmake command hangs when targeting i686 without this patch. Somewhere in the Yocto build flow this causing some change resulting in that hang. I don't know how to find out where the exact problem is though. It looks like only flipping the MSB to 0 fixes the issue, so maybe there is a signed/unsigned issue somewhere? I'll keep digging. Alistair > > Alistair > >> >> >> r~
On 01/18/2018 04:08 PM, Alistair Francis wrote: > Ok, this is not going to be straightforward at all. > > The webkitgtk cmake command hangs when targeting i686 without this > patch. Somewhere in the Yocto build flow this causing some change > resulting in that hang. I don't know how to find out where the exact > problem is though. > > It looks like only flipping the MSB to 0 fixes the issue, so maybe > there is a signed/unsigned issue somewhere? I'll keep digging. There shouldn't be. All of the variables involved on the x86_64 host should be 64-bit. r~
diff --git a/linux-user/main.c b/linux-user/main.c index 450eb3ce65..c7cc0a184e 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -77,7 +77,7 @@ do { \ (TARGET_LONG_BITS == 32 || defined(TARGET_ABI32)) /* There are a number of places where we assign reserved_va to a variable of type abi_ulong and expect it to fit. Avoid the last page. */ -# define MAX_RESERVED_VA (0xfffffffful & TARGET_PAGE_MASK) +# define MAX_RESERVED_VA (0x7ffffffful & TARGET_PAGE_MASK) # else # define MAX_RESERVED_VA (1ul << TARGET_VIRT_ADDR_SPACE_BITS) # endif
Since commit "linux-user: Tidy and enforce reserved_va initialization" (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using musl. To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match to what it was before the problematic commit. Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> --- linux-user/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)