Dear Thomas Neumann,
I am contacting you as the author of the commit with commit hash
6e80a1d164d1f996ad08a512c25a7c2ca893 [1] in the GCC repository. In
this commit, you refactored the __register_frame/__deregister_frame
implementation in GCC. The commit is part of the GCC 13 release.
While
PING.
soe...@soeren-tempel.net wrote:
> From: Sören Tempel
>
> On glibc-based systems, off_t is a 32-bit type on 32-bit systems and a
> 64-bit type on 64-bit systems by default. However, on systems using musl
> libc off_t is unconditionally a 64-bit type. As such, it is insufficient
> to use a
Hello Ian,
Have you had the chance to look at this yet?
Let me know if there is a better way to do this.
Greetings,
Sören
Sören Tempel wrote:
> Hi Ian,
>
> Thanks for your input!
>
> I am not familiar with Go runtime internals at all, but the patch below
> at least compiles for me. Let me
Hi Ian,
Thanks for your input!
I am not familiar with Go runtime internals at all, but the patch below
at least compiles for me. Let me know if this works for you too / if
there is a better way to do this. The untyped uintptr_t seems to be
necessary as otherwise I encountered errors about
Ian Lance Taylor wrote:
> Thanks for the info. Does this patch work? It tweaks the handling of
> SYS_SECCOMP to be specific to that constant.
Yes, your patch works for me too on Alpine Linux Edge.
Thanks!
Greetings,
Sören
Ian Lance Taylor wrote:
> Given that pretty much every one of these musl patches has led to
> problems on some glibc systems, it would be very nice if you could do
> some testing with glibc. Thanks.
Sorry, my bad.
I just tested this on Arch Linux and it compiles fine with the patch.
> Can you
Hi,
The problem is: glibc defines loff_t in sys/types.h, not fcntl.h (where musl
defines it). I falsely assumed that the newly committed AC_CHECK_TYPES
invocation would include fcntl.h *in addition to* AC_INCLUDES_DEFAULT.
However, as it turns out specifying includes for AC_CHECK_TYPES overwrites
t feature check.
>
> With those two modifications your patch works for me (see attachment).
>
> Greetings,
> Sören
>
> Ian Lance Taylor wrote:
> > On Thu, May 12, 2022 at 11:23 AM Sören Tempel via Gcc-patches
> > wrote:
> > >
&
Hi,
Uros Bizjak wrote:
> > > > gcc/ChangeLog:
> > > >
> > > > * config/i386/gnu-user-common.h (defined): Only define
> > > > TARGET_CAN_SPLIT_STACK for glibc targets.
> > > > * config/i386/gnu.h (defined): Ditto.
>
> This looks good to me, so OK.
>
> Thanks,
> Uros.
I am not
Taylor wrote:
> On Thu, May 12, 2022 at 11:23 AM Sören Tempel via Gcc-patches
> wrote:
> >
> > The off64_t type is used for defining Offset_t:
> >
> >
> > https://github.com/golang/gofrontend/blob/4bdff733a0c2a9ddc3eff104b1be03df058a79c4/libgo/mk
Hi Ian,
Thanks for following up on this, comments below.
Ian Lance Taylor wrote:
> I see uses of loff_t but I don't see any uses of off64_t.
The off64_t type is used for defining Offset_t:
PING.
Summary: gcc-go currently assumes that both loff_t and off64_t are defined
as a typedef. However, musl defines them as a CPP macro causing gccgo to
not compile with musl libc.
See: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593527.html
If an alternative solution to the problem
Pinging this again. This time with i386 port maintainers in CC.
Summary: The macro guards for TARGET_CAN_SPLIT_STACK on i386 are not
aligned with the implementation of ix86_supports_split_stack. That is,
on systems using musl libc ix86_supports_split_stack errors-out (since
-fsplit-stack is not
Ian Lance Taylor wrote:
> What I was hoping from my earlier question was that you could tell me
> the exact lines to write in the current sources that will compile on
> MUSL. Don't include , don't refer to earlier patches as
> that is what I tried to do earlier but failed, don't add new #define
>
Hi,
Any updates no this?
Sorry I keep bothering you with this but we are quite literally only a
few lines away from having the go-signal.c code compile on PPC64 musl :)
Let me know if you need more information to get this fixed.
Greetings,
Sören
Sören Tempel wrote:
> Ian Lance Taylor wrote:
Ian Lance Taylor wrote:
> Sorry, I guess I misread your patch.
No problem, I think this stuff is hard to get right and understand in
general since it is so poorly documented.
> What is the right standalone code for the PPC64 musl case? Thanks.
In order to have the current code (i.e. current
Hi Ian,
Thanks for committing a first fix! Unfortunately, your changes don't
work on ppc64le musl since you are now still using .regs on ppc64le the
include of asm/ptrace.h (as added in the v1 of my patch) is missing.
Hence, your patch fails to compile on ppc64le musl with the following
error
Ping.
Would be nice to get this integrated since this one of the changes needed to
make gccgo work with musl libc. Let me know if the patch needs to be revised
further.
Sören Tempel wrote:
> The .regs member is primarily intended to be used in conjunction with
> ptrace. Since this code is not
Ping.
Summary: Currently, the macro guards for TARGET_CAN_SPLIT_STACK are not
aligned with the implementation of ix86_supports_split_stack on x86.
That is, on musl systems TARGET_CAN_SPLIT_STACK is defined even though
-fsplit-stack is not supported (via ix86_supports_split_stack). This
prevents
Ian Lance Taylor wrote:
> Have you tested this in 32-bit mode? It does not look correct based
> on the glibc definitions. Looking at glibc it seems that it ought to
> be
As stated in the commit message, I have only tested this on Alpine Linux
ppc64le (which uses musl libc). Unfortunately, I
What would be the benefit of using .uc_regs instead of .regs? The
current code works entirely fine as it, it just needs an include of the
Linux Kernel header defining the pt_regs type (which my proposed patch
adds).
Furthermore, it seems to me that .uc_regs is only available on powerpc
but not on
Ping.
Summary: Fix build of libgo on PPC with musl libc and libucontext by
explicitly including the Linux header defining `struct pt_regs` instead of
relying on other libc headers to include it implicitly.
See: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587520.html
If the patch
"H.J. Lu" wrote:
> OPTION_GLIBC can't be used here since OPTION_GLIBC is
> evaluated at run-time:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076271.html
Oops, my bad, sorry! This accidentally broke in one of the two cleanup
commits. Originally I justed use TARGET_GLIBC_MAJOR
Ping.
Summary: Patch disable -fstack-split on non-glibc targets to prevent
corruptions of the TCB on libcs which do not support the required
fields in pthread_t. This is an important fix for having gccgo work on
musl by default.
See:
Andrew Pinski wrote:
> I think it should check OPTION_MUSL at runtime instead of
> TARGET_GLIBC_MAJOR at compile time.
> or rather opts->x_linux_libc == LIBC_MUSL
> The others should be done similarly too.
Thanks for pointing this out, I wasn't aware of OPTION_MUSL and
OPTION_GLIBC. However, I
Hi,
Jeff Law wrote:
> So what doesn't make sense here is how both stddef.h files get
> included. That's the core problem I think you need to resolve.
The libgo/sysinfo.c file includes stddef.h (for which the GCC version in
ginclude is used on my system) and stdlib.h which, on musl, causes an
26 matches
Mail list logo
