Re: [PATCH gcc] Hurd x86_64: add unwind support for signal trampoline code

[Samuel Thibault]

Flavio Cruz, le mer. 28 févr. 2024 22:59:09 -0500, a ecrit:
> Tested with some simple toy examples where an exception is thrown in the
> signal handler.
> 
> libgcc/ChangeLog:
>   * config/i386/gnu-unwind.h: Support unwinding x86_64 signal frames.
> 
> Signed-off-by: Flavio Cruz 

Reviewed-by: Samuel Thibault 

Thanks!!

> ---
>  libgcc/config/i386/gnu-unwind.h | 97 -
>  1 file changed, 94 insertions(+), 3 deletions(-)
> 
> diff --git a/libgcc/config/i386/gnu-unwind.h b/libgcc/config/i386/gnu-unwind.h
> index 0751b5593d4..02b060ab4a5 100644
> --- a/libgcc/config/i386/gnu-unwind.h
> +++ b/libgcc/config/i386/gnu-unwind.h
> @@ -32,9 +32,100 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  
>  #ifdef __x86_64__
>  
> -/*
> - * TODO: support for 64 bits needs to be implemented.
> - */
> +#define MD_FALLBACK_FRAME_STATE_FOR x86_gnu_fallback_frame_state
> +
> +static _Unwind_Reason_Code
> +x86_gnu_fallback_frame_state
> +(struct _Unwind_Context *context, _Unwind_FrameState *fs)
> +{
> +  static const unsigned char gnu_sigtramp_code[] =
> +  {
> +/* rpc_wait_trampoline: */
> +0x48, 0xc7, 0xc0, 0xe7, 0xff, 0xff, 0xff,/* mov$-25,%rax */
> +0x0f, 0x05,  /* syscall */
> +0x49, 0x89, 0x04, 0x24,  /* mov%rax,(%r12) */
> +0x48, 0x89, 0xdc,/* mov%rbx,%rsp */
> +
> +/* trampoline: */
> +0x5f,/* pop%rdi */
> +0x5e,/* pop%rsi */
> +0x5a,/* pop%rdx */
> +0x48, 0x83, 0xc4, 0x08,  /* add$0x8,%rsp */
> +0x41, 0xff, 0xd5,/* call   *%r13 */
> +
> +/* RA HERE */
> +0x48, 0x8b, 0x7c, 0x24, 0x10,/* mov0x10(%rsp),%rdi */
> +0xc3,/* ret */
> +
> +/* firewall: */
> +0xf4,/* hlt */
> +  };
> +
> +  const size_t gnu_sigtramp_len = sizeof gnu_sigtramp_code;
> +  const size_t gnu_sigtramp_tail = 7; /* length of tail after RA */
> +
> +  struct stack_contents {
> +void *sigreturn_addr;
> +void *sigreturn_returns_here;
> +struct sigcontext *return_scp;
> +  } *stack_contents;
> +  struct sigcontext *scp;
> +  unsigned long usp;
> +
> +  unsigned char *adjusted_pc = (unsigned char*)(context->ra) +
> +gnu_sigtramp_tail - gnu_sigtramp_len;
> +  if (memcmp (adjusted_pc, gnu_sigtramp_code, gnu_sigtramp_len))
> +return _URC_END_OF_STACK;
> +
> +  stack_contents = context->cfa;
> +
> +  scp = stack_contents->return_scp;
> +  usp = scp->sc_ursp;
> +
> +  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_rax - usp;
> +  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_rdx - usp;
> +  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_rcx - usp;
> +  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_rbx - usp;
> +  fs->regs.reg[4].loc.offset = (unsigned long)&scp->sc_rsi - usp;
> +  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_rdi - usp;
> +  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_rbp - usp;
> +  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_r8 - usp;
> +  fs->regs.reg[9].loc.offset = (unsigned long)&scp->sc_r9 - usp;
> +  fs->regs.reg[10].loc.offset = (unsigned long)&scp->sc_r10 - usp;
> +  fs->regs.reg[11].loc.offset = (unsigned long)&scp->sc_r11 - usp;
> +  fs->regs.reg[12].loc.offset = (unsigned long)&scp->sc_r12 - usp;
> +  fs->regs.reg[13].loc.offset = (unsigned long)&scp->sc_r13 - usp;
> +  fs->regs.reg[14].loc.offset = (unsigned long)&scp->sc_r14 - usp;
> +  fs->regs.reg[15].loc.offset = (unsigned long)&scp->sc_r15 - usp;
> +  fs->regs.reg[16].loc.offset = (unsigned long)&scp->sc_rip - usp;
> +
> +  /* Register 7 is rsp  */
> +  fs->regs.cfa_how = CFA_REG_OFFSET;
> +  fs->regs.cfa_reg = 7;
> +  fs->regs.cfa_offset = usp - (unsigned long) context->cfa;
> +
> +  fs->regs.how[0] = REG_SAVED_OFFSET;
> +  fs->regs.how[1] = REG_SAVED_OFFSET;
> +  fs->regs.how[2] = REG_SAVED_OFFSET;
> +  fs->regs.how[3] = REG_SAVED_OFFSET;
> +  fs->regs.how[4] = REG_SAVED_OFFSET;
> +  fs->regs.how[5] = REG_SAVED_OFFSET;
> +  fs->regs.how[6] = REG_SAVED_OFFSET;
> +  fs->regs.how[8] = REG_SAVED_OFFSET;
> +  fs->regs.how[9] = REG_SAVED_OFFSET;
> +  fs->regs.how[10] = REG_SAVED_OFFSET;
>

Re: hurd: Ad default-pie and static-pie support

[Samuel Thibault]

Thomas Schwinge, le lun. 27 nov. 2023 15:52:02 +0100, a ecrit:
> On 2023-10-28T21:20:39+0200, Samuel Thibault  wrote:
> > This fixes the Hurd spec in the default-pie case, and adds static-pie
> > support.
> 
> I understand that your change does work for you as-is, so I've now pushed
> that to master branch in commit c768917402d4cba69a92c737e56e177f5b8ab0df
> "hurd: Ad default-pie and static-pie support", see attached.

Yes, thanks!
Samuel

> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

> From c768917402d4cba69a92c737e56e177f5b8ab0df Mon Sep 17 00:00:00 2001
> From: Samuel Thibault 
> Date: Sat, 6 May 2023 13:55:44 +0200
> Subject: [PATCH] hurd: Ad default-pie and static-pie support
> 
> This fixes the Hurd spec in the default-pie case, and adds static-pie
> support.
> 
> gcc/ChangeLog:
> 
>   * config/i386/gnu.h: Use PIE_SPEC, add static-pie case.
>   * config/i386/gnu64.h: Use PIE_SPEC, add static-pie case.
> ---
>  gcc/config/i386/gnu.h   | 6 +++---
>  gcc/config/i386/gnu64.h | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
> index 8dc6d9ee4e3..e776144f96c 100644
> --- a/gcc/config/i386/gnu.h
> +++ b/gcc/config/i386/gnu.h
> @@ -27,12 +27,12 @@ along with GCC.  If not, see 
> <http://www.gnu.org/licenses/>.
>  #undef   STARTFILE_SPEC
>  #if defined HAVE_LD_PIE
>  #define STARTFILE_SPEC \
> -  "%{!shared: 
> %{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
>  \
> -   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> +  "%{!shared: 
> %{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
>  PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
> +   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
> ":crtbeginS.o%s;:crtbegin.o%s}"
>  #else
>  #define STARTFILE_SPEC \
>"%{!shared: 
> %{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
> -   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> +   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
>  #endif
>  
>  #ifdef TARGET_LIBC_PROVIDES_SSP
> diff --git a/gcc/config/i386/gnu64.h b/gcc/config/i386/gnu64.h
> index a411f0e802a..332372fa067 100644
> --- a/gcc/config/i386/gnu64.h
> +++ b/gcc/config/i386/gnu64.h
> @@ -31,10 +31,10 @@ along with GCC.  If not, see 
> <http://www.gnu.org/licenses/>.
>  #undef   STARTFILE_SPEC
>  #if defined HAVE_LD_PIE
>  #define STARTFILE_SPEC \
> -  "%{!shared: 
> %{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
>  \
> -   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> +  "%{!shared: 
> %{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
>  PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
> +   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
> ":crtbeginS.o%s;:crtbegin.o%s}"
>  #else
>  #define STARTFILE_SPEC \
>"%{!shared: 
> %{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
> -   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> +   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
> ":crtbeginS.o%s;:crtbegin.o%s}"
>  #endif
> -- 
> 2.34.1
> 


-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: hurd: Add multilib paths for gnu-x86_64

[Samuel Thibault]

Hello,

Thomas Schwinge, le lun. 27 nov. 2023 15:48:33 +0100, a ecrit:
> On 2023-10-28T21:19:59+0200, Samuel Thibault  wrote:
> > This is essentially based on t-linux64 version.
> 
> Yes, but isn't the overall setup diverged from GNU/Linux?

Not sure what you mean exactly?
I just meant that the content of t-gnu64 is almost the same as
t-linux64, the only difference being the multiarch path.

> Currently, x86_64 GNU/Hurd first gets 'i386/t-linux64', whose definitons
> are only later:
> 
> > --- a/gcc/config.gcc
> > +++ b/gcc/config.gcc
> > @@ -5828,6 +5828,9 @@ case ${target} in
> >   visium-*-*)
> >   target_cpu_default2="TARGET_CPU_$with_cpu"
> >   ;;
> > + x86_64-*-gnu*)
> > + tmake_file="$tmake_file i386/t-gnu64"
> > + ;;
> >  esac
> 
> ... then here (effectively) overwritten by 'i386/t-gnu64'.

Yes, like it is done for the x86_64-*-freebsd*) case

> Instead, I suppose, we should handle 'i386/t-linux64' and
> 'i386/t-gnu64' alike, and resolve relevant configuration differences.

So essentially move 

tmake_file="${tmake_file} i386/t-linux64"

down from where it is currently, to the 

# Set some miscellaneous flags for particular targets.
target_cpu_default2=
case ${target} in

part? That should be fine for kfreebsd as well.

> As fas a I can tell, 'i386/t-linux64' is also used for multilib-enabled
> ('test x$enable_targets = xall') x86 GNU/Linux, and that's not
> (correspondingly) done for x86 GNU/Hurd?

We don't really plan to support 32/64 multilib support in GNU/Hurd.

> However, such things can certainly be resolved incrementally, later on.
> I understand that your change does work for you as-is,

Thanks for your understanding :) that'll help pushing further in Debian.

Samuel

[PATCH,resend] hurd: Ad default-pie and static-pie support

[Samuel Thibault]

This fixes the Hurd spec in the default-pie case, and adds static-pie
support.

gcc/ChangeLog:

* gcc/config/i386/gnu.h: Use PIE_SPEC, add static-pie case.
* gcc/config/i386/gnu64.h: Use PIE_SPEC, add static-pie case.

diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
index 8dc6d9ee4e3..e776144f96c 100644
--- a/gcc/config/i386/gnu.h
+++ b/gcc/config/i386/gnu.h
@@ -27,12 +27,12 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
 #endif
 
 #ifdef TARGET_LIBC_PROVIDES_SSP
diff --git a/gcc/config/i386/gnu64.h b/gcc/config/i386/gnu64.h
index a411f0e802a..332372fa067 100644
--- a/gcc/config/i386/gnu64.h
+++ b/gcc/config/i386/gnu64.h
@@ -31,10 +31,10 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #endif

[PATCH,resend] hurd: Add multilib paths for gnu-x86_64

[Samuel Thibault]

We need the multilib paths in gcc to find e.g. glibc crt files on
Debian.  This is essentially based on t-linux64 version.

gcc/ChangeLog:

* gcc/config/i386/t-gnu64: New file.
* gcc/config.gcc [x86_64-*-gnu*): Add i386/t-gnu64 to
tmake_file.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 671c7e3b018..6b1939b9f09 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5828,6 +5828,9 @@ case ${target} in
visium-*-*)
target_cpu_default2="TARGET_CPU_$with_cpu"
;;
+   x86_64-*-gnu*)
+   tmake_file="$tmake_file i386/t-gnu64"
+   ;;
 esac
 
 t=
diff --git a/gcc/config/i386/t-gnu64 b/gcc/config/i386/t-gnu64
index e69de29bb2d..23ee6823d65 100644
--- a/gcc/config/i386/t-gnu64
+++ b/gcc/config/i386/t-gnu64
@@ -0,0 +1,38 @@
+# Copyright (C) 2002-2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
+# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
+# /lib and /usr/lib, while other distributions install libraries into /lib64
+# and /usr/lib64.  The LSB does not enforce the use of /lib64 and /usr/lib64,
+# it doesn't tell anything about the 32bit libraries on those systems.  Set
+# MULTILIB_OSDIRNAMES according to what is found on the target.
+
+# To support i386, x86-64 and x32 libraries, the directory structrue
+# should be:
+#
+#  /lib has i386 libraries.
+#  /lib64 has x86-64 libraries.
+#  /libx32 has x32 libraries.
+#
+comma=,
+MULTILIB_OPTIONS= $(subst $(comma),/,$(TM_MULTILIB_CONFIG))
+MULTILIB_DIRNAMES   = $(patsubst m%, %, $(subst /, ,$(MULTILIB_OPTIONS)))
+MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-gnu)
+MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
if_multiarch,:i386-gnu)
+MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-gnux32)

Re: [PATCH] hurd: Add multilib paths for gnu-x86_64

[Samuel Thibault via Gcc-patches]

(and it'd be useful to have it backported to the 13 branch)

Samuel Thibault, le sam. 06 mai 2023 13:50:36 +0200, a ecrit:
> We need the multilib paths in gcc to find e.g. glibc crt files on
> Debian.  This is essentially based on t-linux64 version.
> 
> gcc/ChangeLog:
> 
>   * gcc/config/i386/t-gnu64: New file.
>   * gcc/config.gcc [x86_64-*-gnu*): Add i386/t-gnu64 to
>   tmake_file.
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 671c7e3b018..6b1939b9f09 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -5828,6 +5828,9 @@ case ${target} in
>   visium-*-*)
>   target_cpu_default2="TARGET_CPU_$with_cpu"
>   ;;
> + x86_64-*-gnu*)
> + tmake_file="$tmake_file i386/t-gnu64"
> + ;;
>  esac
>  
>  t=
> diff --git a/gcc/config/i386/t-gnu64 b/gcc/config/i386/t-gnu64
> index e69de29bb2d..23ee6823d65 100644
> --- a/gcc/config/i386/t-gnu64
> +++ b/gcc/config/i386/t-gnu64
> @@ -0,0 +1,38 @@
> +# Copyright (C) 2002-2023 Free Software Foundation, Inc.
> +#
> +# This file is part of GCC.
> +#
> +# GCC is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3, or (at your option)
> +# any later version.
> +#
> +# GCC is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with GCC; see the file COPYING3.  If not see
> +# <http://www.gnu.org/licenses/>.
> +
> +# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
> +# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
> +# /lib and /usr/lib, while other distributions install libraries into /lib64
> +# and /usr/lib64.  The LSB does not enforce the use of /lib64 and /usr/lib64,
> +# it doesn't tell anything about the 32bit libraries on those systems.  Set
> +# MULTILIB_OSDIRNAMES according to what is found on the target.
> +
> +# To support i386, x86-64 and x32 libraries, the directory structrue
> +# should be:
> +#
> +#/lib has i386 libraries.
> +#/lib64 has x86-64 libraries.
> +#/libx32 has x32 libraries.
> +#
> +comma=,
> +MULTILIB_OPTIONS= $(subst $(comma),/,$(TM_MULTILIB_CONFIG))
> +MULTILIB_DIRNAMES   = $(patsubst m%, %, $(subst /, ,$(MULTILIB_OPTIONS)))
> +MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-gnu)
> +MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo 
> $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
> if_multiarch,:i386-gnu)
> +MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-gnux32)

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

[PATCH] hurd: Ad default-pie and static-pie support

[Samuel Thibault via Gcc-patches]

This fixes the Hurd spec in the default-pie case, and adds static-pie
support.

gcc/ChangeLog:

* gcc/config/i386/gnu.h: Use PIE_SPEC, add static-pie case.
* gcc/config/i386/gnu64.h: Use PIE_SPEC, add static-pie case.

diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
index 8dc6d9ee4e3..e776144f96c 100644
--- a/gcc/config/i386/gnu.h
+++ b/gcc/config/i386/gnu.h
@@ -27,12 +27,12 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
 #endif
 
 #ifdef TARGET_LIBC_PROVIDES_SSP
diff --git a/gcc/config/i386/gnu64.h b/gcc/config/i386/gnu64.h
index a411f0e802a..332372fa067 100644
--- a/gcc/config/i386/gnu64.h
+++ b/gcc/config/i386/gnu64.h
@@ -31,10 +31,10 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #endif

[PATCH] hurd: Add multilib paths for gnu-x86_64

[Samuel Thibault via Gcc-patches]

We need the multilib paths in gcc to find e.g. glibc crt files on
Debian.  This is essentially based on t-linux64 version.

gcc/ChangeLog:

* gcc/config/i386/t-gnu64: New file.
* gcc/config.gcc [x86_64-*-gnu*): Add i386/t-gnu64 to
tmake_file.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 671c7e3b018..6b1939b9f09 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5828,6 +5828,9 @@ case ${target} in
visium-*-*)
target_cpu_default2="TARGET_CPU_$with_cpu"
;;
+   x86_64-*-gnu*)
+   tmake_file="$tmake_file i386/t-gnu64"
+   ;;
 esac
 
 t=
diff --git a/gcc/config/i386/t-gnu64 b/gcc/config/i386/t-gnu64
index e69de29bb2d..23ee6823d65 100644
--- a/gcc/config/i386/t-gnu64
+++ b/gcc/config/i386/t-gnu64
@@ -0,0 +1,38 @@
+# Copyright (C) 2002-2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
+# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
+# /lib and /usr/lib, while other distributions install libraries into /lib64
+# and /usr/lib64.  The LSB does not enforce the use of /lib64 and /usr/lib64,
+# it doesn't tell anything about the 32bit libraries on those systems.  Set
+# MULTILIB_OSDIRNAMES according to what is found on the target.
+
+# To support i386, x86-64 and x32 libraries, the directory structrue
+# should be:
+#
+#  /lib has i386 libraries.
+#  /lib64 has x86-64 libraries.
+#  /libx32 has x32 libraries.
+#
+comma=,
+MULTILIB_OPTIONS= $(subst $(comma),/,$(TM_MULTILIB_CONFIG))
+MULTILIB_DIRNAMES   = $(patsubst m%, %, $(subst /, ,$(MULTILIB_OPTIONS)))
+MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-gnu)
+MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
if_multiarch,:i386-gnu)
+MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-gnux32)

[PATCH]: Fix static-pie on Hurd target

[Samuel Thibault via Gcc-patches]

When linking with -static-pie, we need to use rcrt0.o (and grcrt0.o for
-pg). Also, set static:crt0.o before pie:Scrt1.o, otherwise -static -pie
fails to link with Scrt1.o due to missing _DYNAMIC symbol.

Also, -static-pie needs crtbeginS.o (otherwise it contains a relocation
in read-only .text).

And eventually, when HAVE_LD_PIE is not defined, there is no reason to
include the pie case

gcc/ChangeLog

* gcc/config/i386/gnu.h (STARTFILE_SPEC): Add static-pie cases
and fix -static -pie case.

---
 gcc/config/i386/gnu.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
index fb8d69a97d8..7d7bfa7da7b 100644
--- a/gcc/config/i386/gnu.h
+++ b/gcc/config/i386/gnu.h
@@ -27,12 +27,12 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;pie:Scrt1.o%s;:crt1.o%s}}
 \
+   crti.o%s 
%{static:crtbeginT.o%s;shared|pie|static-pie:crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
 #endif
 
 #ifdef TARGET_LIBC_PROVIDES_SSP

[PATCHv2] libstdc++: Mark pieces of gnu-linux/os_support.h linux-specific

[Samuel Thibault via Gcc-patches]

This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.

The pthread_self() function can also always be used fine as it is on
GNU/Hurd.

libstdc++-v3/ChangeLog:

* config/os/gnu-linux/os_defines.h [!__linux__]
  (_GLIBCXX_NATIVE_THREAD_ID, _GLIBCXX_GTHREAD_USE_WEAK): Do not define.

diff --git a/libstdc++-v3/config/os/gnu-linux/os_defines.h 
b/libstdc++-v3/config/os/gnu-linux/os_defines.h
index c0caa21a013..4de93d752e1 100644
--- a/libstdc++-v3/config/os/gnu-linux/os_defines.h
+++ b/libstdc++-v3/config/os/gnu-linux/os_defines.h
@@ -49,22 +49,24 @@
 // version dynamically in case it has changed since libstdc++ was configured.
 #define _GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC __GLIBC_PREREQ(2,23)
 
-#if __GLIBC_PREREQ(2, 27)
-// Since glibc 2.27 pthread_self() is usable without linking to libpthread.
-# define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
-#else
+#ifdef __linux__
+# if __GLIBC_PREREQ(2, 27)
+// Since glibc 2.27 Linux' pthread_self() is usable without linking to 
libpthread.
+#  define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
+# else
 // Before then it was in libc.so.6 but not libc.a, and always returns 0,
 // which breaks the invariant this_thread::get_id() != thread::id{}.
 // So only use it if we know the libpthread version is available.
 // Otherwise use (__gthread_t)1 as the ID of the main (and only) thread.
-# define _GLIBCXX_NATIVE_THREAD_ID \
-  (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
-#endif
+#  define _GLIBCXX_NATIVE_THREAD_ID \
+   (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
+# endif
 
-#if __GLIBC_PREREQ(2, 34)
-// Since glibc 2.34 all pthreads functions are usable without linking to
+# if __GLIBC_PREREQ(2, 34)
+// Since glibc 2.34 all Linux pthreads functions are usable without linking to
 // libpthread.
-# define _GLIBCXX_GTHREAD_USE_WEAK 0
+#  define _GLIBCXX_GTHREAD_USE_WEAK 0
+# endif
 #endif
 
 #endif

Re: [PATCH] libstdc++: Introduce GNU/Hurd-specific libstdc++ os-defines.h

[Samuel Thibault via Gcc-patches]

Hello,

Jonathan Wakely, le ven. 07 oct. 2022 12:14:26 +0100, a ecrit:
> As documented at https://gcc.gnu.org/lists.html all patches for
> libstdc++ need to be CC'd to the libstdc++ list. That's why your patch
> has not been reviewed, because I didn't see it.

Ah, sorry, I hadn't noticed that.

> On 29/08/22 02:30 +0200, Samuel Thibault wrote:
> > This is notably needed because in glibc 2.34, the move of pthread functions
> > into libc.so happened for Linux only, not GNU/Hurd.
> > 
> > The pthread_self() function can also always be used fine as it is.
> > 
> > libstdc++-v3/ChangeLog:
> 
> > 
> >* config/os/gnu/os_defines.h: New file.
> >* config/os/gnu/ctype_base.h: New file.
> >* config/os/gnu/ctype_configure_char.cc: New file.
> >* config/os/gnu/ctype_inline.h: New file.
> >* configure.host: On gnu* host, use os/gnu instead of os/gnu-linux.
> 
> I think the commit message should note that these files are all copied
> from the existing gnu-linux ones, so that the git log records that and
> people don't need to compare them manually.
> 
> But if these files are all identical to the existing gnu-linux ones,
> except for a couple of macros in os_defines.h being conditional on
> Linux, why not just test __linux__ in os_defines.h?

Ah, it's just that I hadn't seen that done for other OSes, even when
they are very similar (e.g. between gnu-linux and uclibc).

If #ifdef is fine there, then yes I'm all for it indeed. I'll send a v2.

Samuel

Re: [PATCH] libstdc++: Introduce GNU/Hurd-specific libstdc++ os-defines.h

[Samuel Thibault via Gcc-patches]

Ping?

Samuel Thibault, le lun. 29 août 2022 02:30:40 +0200, a ecrit:
> This is notably needed because in glibc 2.34, the move of pthread functions
> into libc.so happened for Linux only, not GNU/Hurd.
> 
> The pthread_self() function can also always be used fine as it is.
> 
> libstdc++-v3/ChangeLog:
> 
> * config/os/gnu/os_defines.h: New file.
> * config/os/gnu/ctype_base.h: New file.
> * config/os/gnu/ctype_configure_char.cc: New file.
> * config/os/gnu/ctype_inline.h: New file.
> * configure.host: On gnu* host, use os/gnu instead of os/gnu-linux.
> 
> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
> index ba5939d9003..dd288cce2ca 100644
> --- a/libstdc++-v3/ChangeLog
> +++ b/libstdc++-v3/ChangeLog
> @@ -1,3 +1,11 @@
> +2022-08-28  Samuel Thibault  
> +
> + * config/os/gnu/os_defines.h: New file.
> + * config/os/gnu/ctype_base.h: New file.
> + * config/os/gnu/ctype_configure_char.cc: New file.
> + * config/os/gnu/ctype_inline.h: New file.
> + * configure.host: On gnu* host, use os/gnu instead of os/gnu-linux.
> +
>  2022-08-27  Patrick Palka  
>  
>   * testsuite/20_util/logical_traits/requirements/base_classes.cc: New 
> test.
> diff --git a/libstdc++-v3/config/os/gnu/ctype_base.h 
> b/libstdc++-v3/config/os/gnu/ctype_base.h
> new file mode 100644
> index 000..955146543db
> --- /dev/null
> +++ b/libstdc++-v3/config/os/gnu/ctype_base.h
> @@ -0,0 +1,66 @@
> +// Locale support -*- C++ -*-
> +
> +// Copyright (C) 1997-2022 Free Software Foundation, Inc.
> +//
> +// This file is part of the GNU ISO C++ Library.  This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +// GNU General Public License for more details.
> +
> +// Under Section 7 of GPL version 3, you are granted additional
> +// permissions described in the GCC Runtime Library Exception, version
> +// 3.1, as published by the Free Software Foundation.
> +
> +// You should have received a copy of the GNU General Public License and
> +// a copy of the GCC Runtime Library Exception along with this program;
> +// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +// <http://www.gnu.org/licenses/>.
> +
> +/** @file bits/ctype_base.h
> + *  This is an internal header file, included by other library headers.
> + *  Do not attempt to use it directly. @headername{locale}
> + */
> +
> +//
> +// ISO C++ 14882: 22.1  Locales
> +//
> +
> +// Information as gleaned from /usr/include/ctype.h
> +
> +namespace std _GLIBCXX_VISIBILITY(default)
> +{
> +_GLIBCXX_BEGIN_NAMESPACE_VERSION
> +
> +  /// @brief  Base class for ctype.
> +  struct ctype_base
> +  {
> +// Non-standard typedefs.
> +typedef const int*   __to_type;
> +
> +// NB: Offsets into ctype::_M_table force a particular size
> +// on the mask type. Because of this, we don't use an enum.
> +typedef unsigned short   mask;
> +static const mask upper  = _ISupper;
> +static const mask lower  = _ISlower;
> +static const mask alpha  = _ISalpha;
> +static const mask digit  = _ISdigit;
> +static const mask xdigit = _ISxdigit;
> +static const mask space  = _ISspace;
> +static const mask print  = _ISprint;
> +static const mask graph  = _ISalpha | _ISdigit | _ISpunct;
> +static const mask cntrl  = _IScntrl;
> +static const mask punct  = _ISpunct;
> +static const mask alnum  = _ISalpha | _ISdigit;
> +#if __cplusplus >= 201103L
> +static const mask blank  = _ISblank;
> +#endif
> +  };
> +
> +_GLIBCXX_END_NAMESPACE_VERSION
> +} // namespace
> diff --git a/libstdc++-v3/config/os/gnu/ctype_configure_char.cc 
> b/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
> new file mode 100644
> index 000..5a88fc11ab3
> --- /dev/null
> +++ b/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
> @@ -0,0 +1,196 @@
> +// Locale support -*- C++ -*-
> +
> +// Copyright (C) 2011-2022 Free Software Foundation, Inc.
> +//
> +// This file is part of the GNU ISO C++ Library.  This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either v

[PATCH] libstdc++: Introduce GNU/Hurd-specific libstdc++ os-defines.h

[Samuel Thibault via Gcc-patches]

This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.

The pthread_self() function can also always be used fine as it is.

libstdc++-v3/ChangeLog:

* config/os/gnu/os_defines.h: New file.
* config/os/gnu/ctype_base.h: New file.
* config/os/gnu/ctype_configure_char.cc: New file.
* config/os/gnu/ctype_inline.h: New file.
* configure.host: On gnu* host, use os/gnu instead of os/gnu-linux.

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index ba5939d9003..dd288cce2ca 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,11 @@
+2022-08-28  Samuel Thibault  
+
+   * config/os/gnu/os_defines.h: New file.
+   * config/os/gnu/ctype_base.h: New file.
+   * config/os/gnu/ctype_configure_char.cc: New file.
+   * config/os/gnu/ctype_inline.h: New file.
+   * configure.host: On gnu* host, use os/gnu instead of os/gnu-linux.
+
 2022-08-27  Patrick Palka  
 
* testsuite/20_util/logical_traits/requirements/base_classes.cc: New 
test.
diff --git a/libstdc++-v3/config/os/gnu/ctype_base.h 
b/libstdc++-v3/config/os/gnu/ctype_base.h
new file mode 100644
index 000..955146543db
--- /dev/null
+++ b/libstdc++-v3/config/os/gnu/ctype_base.h
@@ -0,0 +1,66 @@
+// Locale support -*- C++ -*-
+
+// Copyright (C) 1997-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// <http://www.gnu.org/licenses/>.
+
+/** @file bits/ctype_base.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{locale}
+ */
+
+//
+// ISO C++ 14882: 22.1  Locales
+//
+
+// Information as gleaned from /usr/include/ctype.h
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  /// @brief  Base class for ctype.
+  struct ctype_base
+  {
+// Non-standard typedefs.
+typedef const int* __to_type;
+
+// NB: Offsets into ctype::_M_table force a particular size
+// on the mask type. Because of this, we don't use an enum.
+typedef unsigned short mask;
+static const mask upper= _ISupper;
+static const mask lower= _ISlower;
+static const mask alpha= _ISalpha;
+static const mask digit= _ISdigit;
+static const mask xdigit   = _ISxdigit;
+static const mask space= _ISspace;
+static const mask print= _ISprint;
+static const mask graph= _ISalpha | _ISdigit | _ISpunct;
+static const mask cntrl= _IScntrl;
+static const mask punct= _ISpunct;
+static const mask alnum= _ISalpha | _ISdigit;
+#if __cplusplus >= 201103L
+static const mask blank= _ISblank;
+#endif
+  };
+
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace
diff --git a/libstdc++-v3/config/os/gnu/ctype_configure_char.cc 
b/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
new file mode 100644
index 000..5a88fc11ab3
--- /dev/null
+++ b/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
@@ -0,0 +1,196 @@
+// Locale support -*- C++ -*-
+
+// Copyright (C) 2011-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along wit

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Hello,

Joseph Myers, le lun. 18 janv. 2021 20:05:44 +, a ecrit:
> On Wed, 13 Jan 2021, Thomas Schwinge wrote:
> > Thanks (and sorry for the delay), pushed "Hurd: Enable ifunc by default"
> > to master branch in commit e9cb89b936f831a02318d45fc4ddb06f7be55ae4, and
> > cherry-picked into releases/gcc-10 branch in commit
> > 92b131491c22eb4e4b663d226e9d97f1fd693063, releases/gcc-9 branch in commit
> > 0313ce139f4ca3c96db9dc82125ec9e4a167a224, releases/gcc-8 branch in commit
> > 975b0fa0f43e84bed3cb1b2b593132bc219f962c, see attached.
> 
> I'm not sure what toolchain component the underlying bug is in, but this 
> GCC commit (verified in the releases/gcc-10 case) results in a glibc build 
> failure for i686-gnu with build-many-glibcs.py.
> 
> https://sourceware.org/pipermail/libc-testresults/2021q1/007378.html
> 
> The error is:
> 
> /scratch/jmyers/glibc-bot/install/compilers/i686-gnu/lib/gcc/i686-glibc-gnu/11.0.0/../../../../i686-glibc-gnu/bin/ld:
>  
> /scratch/jmyers/glibc-bot/build/compilers/i686-gnu/glibc/i686-gnu/elf/librtld.os:
>  in function `hurd_file_name_lookup_retry':
> (.text+0x1e08e): undefined reference to `strncpy'

Ah, I believe I had tested that (which is precisely why I asked for that
commit to be done in gcc), but I'll have a look, thanks.

Samuel

Re: [PATCHv2] hurd: libgcc unwinding over signal trampolines with SIGINFO

[Samuel Thibault via Gcc-patches]

Ping?

Samuel Thibault, le lun. 21 déc. 2020 15:36:30 +0100, a ecrit:

When the application sets SA_SIGINFO, the signal trampoline parameters
are different to follow POSIX.

libgcc/
* config/i386/gnu-unwind.h (x86_gnu_fallback_frame_state): Add the posix
siginfo case to struct handler_args. Detect between legacy and siginfo from
the second parameter, which is a small sigcode in the legacy case, and a
pointer in the siginfo case.

diff --git a/libgcc/config/i386/gnu-unwind.h b/libgcc/config/i386/gnu-unwind.h
index db47f0ac1d4..f83411e3de4 100644
--- a/libgcc/config/i386/gnu-unwind.h
+++ b/libgcc/config/i386/gnu-unwind.h
@@ -38,10 +38,21 @@ x86_gnu_fallback_frame_state
 {
   struct handler_args {
 int signo;
-int sigcode;
-struct sigcontext *scp;
+union
+  {
+   struct
+ {
+   long int sigcode;
+   struct sigcontext *scp;
+ } legacy;
+   struct
+ {
+   siginfo_t *siginfop;
+   ucontext_t *uctxp;
+ } posix;
+  };
   } *handler_args;
-  struct sigcontext *scp;
+  long int sigcode;
   unsigned long usp;
 
 /*
@@ -75,29 +86,52 @@ x86_gnu_fallback_frame_state
 return _URC_END_OF_STACK;
 
   handler_args = context->cfa;
-  scp = handler_args->scp;
-  usp = scp->sc_uesp;
+  sigcode = handler_args->legacy.sigcode;
+  if (sigcode >= -16 && sigcode < 4096)
+{
+  /* This cannot be a SIGINFO pointer, assume legacy.  */
+  struct sigcontext *scp = handler_args->legacy.scp;
+  usp = scp->sc_uesp;
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+}
+  else
+{
+  /* This is not a valid sigcode, assume SIGINFO.  */
+  ucontext_t *uctxp = handler_args->posix.uctxp;
+  gregset_t *gregset = &uctxp->uc_mcontext.gregs;
+  usp = (*gregset)[REG_UESP];
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&(*gregset)[REG_EAX] - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&(*gregset)[REG_ECX] - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&(*gregset)[REG_EDX] - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&(*gregset)[REG_EBX] - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&(*gregset)[REG_EBP] - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&(*gregset)[REG_ESI] - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&(*gregset)[REG_EDI] - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&(*gregset)[REG_EIP] - usp;
+}
 
   fs->regs.cfa_how = CFA_REG_OFFSET;
   fs->regs.cfa_reg = 4;
   fs->regs.cfa_offset = usp - (unsigned long) context->cfa;
 
   fs->regs.reg[0].how = REG_SAVED_OFFSET;
-  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
   fs->regs.reg[1].how = REG_SAVED_OFFSET;
-  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
   fs->regs.reg[2].how = REG_SAVED_OFFSET;
-  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
   fs->regs.reg[3].how = REG_SAVED_OFFSET;
-  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
   fs->regs.reg[5].how = REG_SAVED_OFFSET;
-  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
   fs->regs.reg[6].how = REG_SAVED_OFFSET;
-  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
   fs->regs.reg[7].how = REG_SAVED_OFFSET;
-  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
   fs->regs.reg[8].how = REG_SAVED_OFFSET;
-  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+
   fs->retaddr_column = 8;
   fs->signal_frame = 1;
 

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Ping?

Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
> 
> 2020-11-08  Samuel Thibault  
> 
>   gcc/
>   * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
>   target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu).
> ---
>  gcc/config.gcc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b42ebc4e5be..a347c2cec7c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3538,7 +3538,9 @@ esac
>  case ${target} in
>  *-*-linux*android*|*-*-linux*uclibc*|*-*-linux*musl*)
>  ;;
> -*-*-linux*)
> +*-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> +;;
> +*-*-linux* | *-*-gnu*)
>   case ${target} in
>   aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | 
> x86_64-*)
>   default_gnu_indirect_function=yes
> -- 
> 2.20.1
> 

Re: [PATCH] libtool.m4: update GNU/Hurd test from upstream

[Samuel Thibault via Gcc-patches]

Jeff Law, le mar. 05 janv. 2021 16:04:45 -0700, a ecrit:
> Thanks.  Installed.

Thanks!

Samuel

Re: [PATCH] libtool.m4: update GNU/Hurd test from upstream

[Samuel Thibault via Gcc-patches]

Hello,

Jeff Law, le lun. 04 janv. 2021 13:29:53 -0700, a ecrit:
> On 12/23/20 6:12 PM, Samuel Thibault wrote:
> > In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
> > detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
> > This backports it.
> >
> > ChangeLog:
> >
> > * libtool.m4: Match gnu* along other GNU systems.
> > * libffi/configure: Re-generate.
> > * libgomp/configure: Re-generate.
> >
> > * libgo/config/libtool.m4: Match gnu* along other GNU systems.
> > * libgo/configure: Re-generate.
> OK for the trunk.

(I do not have commit access to gcc)

Samuel

[PATCH] libtool.m4: update GNU/Hurd test from upstream

[Samuel Thibault]

In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
This backports it.

ChangeLog:

* libtool.m4: Match gnu* along other GNU systems.
* libffi/configure: Re-generate.
* libgomp/configure: Re-generate.

* libgo/config/libtool.m4: Match gnu* along other GNU systems.
* libgo/configure: Re-generate.

gcc/ChangeLog:

* configure: Re-generate.

libatomic/ChangeLog:

* configure: Re-generate.

libbacktrace/ChangeLog:

* configure: Re-generate.

libcc1/ChangeLog:

* configure: Re-generate.

libgfortran/ChangeLog:

* configure: Re-generate.

libgomp/ChangeLog:

* configure: Re-generate.

libhsail-rt/ChangeLog:

* configure: Re-generate.

libitm/ChangeLog:

* configure: Re-generate.

libobjc/ChangeLog:

* configure: Re-generate.

liboffloadmic/ChangeLog:

* configure: Re-generate.
* plugin/configure: Re-generate.

libphobos/ChangeLog:

* configure: Re-generate.

libquadmath/ChangeLog:

* configure: Re-generate.

libsanitizer/ChangeLog:

* configure: Re-generate.

libssp/ChangeLog:

* configure: Re-generate.

libstdc++-v3/ChangeLog:

* configure: Re-generate.

libvtv/ChangeLog:

* configure: Re-generate.

lto-plugin/ChangeLog:

* configure: Re-generate.

zlib/ChangeLog:

* configure: Re-generate.
---
 gcc/configure  | 12 +---
 libatomic/configure| 12 +---
 libbacktrace/configure | 12 +---
 libcc1/configure   | 12 +---
 libffi/configure   | 12 +---
 libgfortran/configure  | 12 +---
 libgo/config/libtool.m4| 12 +---
 libgo/configure| 12 +---
 libgomp/configure  | 12 +---
 libhsail-rt/configure  | 12 +---
 libitm/configure   | 12 +---
 libobjc/configure  | 12 +---
 liboffloadmic/configure| 12 +---
 liboffloadmic/plugin/configure | 12 +---
 libphobos/configure| 12 +---
 libquadmath/configure  | 12 +---
 libsanitizer/configure | 12 +---
 libssp/configure   | 12 +---
 libstdc++-v3/configure | 12 +---
 libtool.m4 | 12 +---
 libvtv/configure   | 12 +---
 lto-plugin/configure   | 12 +---
 zlib/configure | 12 +---
 23 files changed, 23 insertions(+), 253 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index fbe92089640..9a25dacf8b3 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -18366,16 +18366,6 @@ freebsd* | dragonfly*)
   esac
   ;;
 
-gnu*)
-  version_type=linux
-  need_lib_prefix=no
-  need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
-  shlibpath_var=LD_LIBRARY_PATH
-  hardcode_into_libs=yes
-  ;;
-
 haiku*)
   version_type=linux
   need_lib_prefix=no
@@ -18497,7 +18487,7 @@ linux*oldld* | linux*aout* | linux*coff*)
 # project, but have not yet been accepted: they are GCC-local changes
 # for the time being.  (See
 # https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
-linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu* | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no
diff --git a/libatomic/configure b/libatomic/configure
index 50fe5480b78..5867e69ac14 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -10570,16 +10570,6 @@ freebsd* | dragonfly*)
   esac
   ;;
 
-gnu*)
-  version_type=linux
-  need_lib_prefix=no
-  need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
-  shlibpath_var=LD_LIBRARY_PATH
-  hardcode_into_libs=yes
-  ;;
-
 haiku*)
   version_type=linux
   need_lib_prefix=no
@@ -10701,7 +10691,7 @@ linux*oldld* | linux*aout* | linux*coff*)
 # project, but have not yet been accepted: they are GCC-local changes
 # for the time being.  (See
 # https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
-linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu* | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 665adef7566..86e387f0ca5 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -10699,16 +10699,6 @@ freebsd* | dragonfly*)
   esac
   ;;
 
-gnu*)
-  version_type=linux
-  need_lib_prefix=no

[PATCHv2] hurd: libgcc unwinding over signal trampolines with SIGINFO

[Samuel Thibault via Gcc-patches]

When the application sets SA_SIGINFO, the signal trampoline parameters
are different to follow POSIX.

libgcc/
* config/i386/gnu-unwind.h (x86_gnu_fallback_frame_state): Add the posix
siginfo case to struct handler_args. Detect between legacy and siginfo from
the second parameter, which is a small sigcode in the legacy case, and a
pointer in the siginfo case.

diff --git a/libgcc/config/i386/gnu-unwind.h b/libgcc/config/i386/gnu-unwind.h
index db47f0ac1d4..f83411e3de4 100644
--- a/libgcc/config/i386/gnu-unwind.h
+++ b/libgcc/config/i386/gnu-unwind.h
@@ -38,10 +38,21 @@ x86_gnu_fallback_frame_state
 {
   struct handler_args {
 int signo;
-int sigcode;
-struct sigcontext *scp;
+union
+  {
+   struct
+ {
+   long int sigcode;
+   struct sigcontext *scp;
+ } legacy;
+   struct
+ {
+   siginfo_t *siginfop;
+   ucontext_t *uctxp;
+ } posix;
+  };
   } *handler_args;
-  struct sigcontext *scp;
+  long int sigcode;
   unsigned long usp;
 
 /*
@@ -75,29 +86,52 @@ x86_gnu_fallback_frame_state
 return _URC_END_OF_STACK;
 
   handler_args = context->cfa;
-  scp = handler_args->scp;
-  usp = scp->sc_uesp;
+  sigcode = handler_args->legacy.sigcode;
+  if (sigcode >= -16 && sigcode < 4096)
+{
+  /* This cannot be a SIGINFO pointer, assume legacy.  */
+  struct sigcontext *scp = handler_args->legacy.scp;
+  usp = scp->sc_uesp;
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+}
+  else
+{
+  /* This is not a valid sigcode, assume SIGINFO.  */
+  ucontext_t *uctxp = handler_args->posix.uctxp;
+  gregset_t *gregset = &uctxp->uc_mcontext.gregs;
+  usp = (*gregset)[REG_UESP];
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&(*gregset)[REG_EAX] - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&(*gregset)[REG_ECX] - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&(*gregset)[REG_EDX] - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&(*gregset)[REG_EBX] - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&(*gregset)[REG_EBP] - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&(*gregset)[REG_ESI] - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&(*gregset)[REG_EDI] - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&(*gregset)[REG_EIP] - usp;
+}
 
   fs->regs.cfa_how = CFA_REG_OFFSET;
   fs->regs.cfa_reg = 4;
   fs->regs.cfa_offset = usp - (unsigned long) context->cfa;
 
   fs->regs.reg[0].how = REG_SAVED_OFFSET;
-  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
   fs->regs.reg[1].how = REG_SAVED_OFFSET;
-  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
   fs->regs.reg[2].how = REG_SAVED_OFFSET;
-  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
   fs->regs.reg[3].how = REG_SAVED_OFFSET;
-  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
   fs->regs.reg[5].how = REG_SAVED_OFFSET;
-  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
   fs->regs.reg[6].how = REG_SAVED_OFFSET;
-  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
   fs->regs.reg[7].how = REG_SAVED_OFFSET;
-  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
   fs->regs.reg[8].how = REG_SAVED_OFFSET;
-  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+
   fs->retaddr_column = 8;
   fs->signal_frame = 1;
 

Re: [PATCH] hurd: libgcc unwinding over signal trampolines with SIGINFO

[Samuel Thibault via Gcc-patches]

Jessica Clarke, le lun. 21 déc. 2020 14:21:39 +, a ecrit:
> On 21 Dec 2020, at 14:09, Samuel Thibault  wrote:
> > @@ -75,29 +86,52 @@ x86_gnu_fallback_frame_state
> > return _URC_END_OF_STACK;
> > 
> >   handler_args = context->cfa;
> > -  scp = handler_args->scp;
> > -  usp = scp->sc_uesp;
> > +  sigcode = handler_args->legacy.sigcode;
> > +  if (sigcode < 4096)
> 
> Do you not need >= 0 to handle the 3/1 split correctly?

Ah, right, that's an signed integer, I'll add that.

Thanks,
Samuel

[PATCH] hurd: libgcc unwinding over signal trampolines with SIGINFO

[Samuel Thibault via Gcc-patches]

When the application sets SA_SIGINFO, the signal trampoline parameters
are different to follow POSIX.

libgcc/
* config/i386/gnu-unwind.h (x86_gnu_fallback_frame_state): Add the posix
siginfo case to struct handler_args. Detect between legacy and siginfo from
the second parameter, which is a small sigcode in the legacy case, and a
pointer in the siginfo case.

diff --git a/libgcc/config/i386/gnu-unwind.h b/libgcc/config/i386/gnu-unwind.h
index db47f0ac1d4..3eefe7de7e5 100644
--- a/libgcc/config/i386/gnu-unwind.h
+++ b/libgcc/config/i386/gnu-unwind.h
@@ -38,10 +38,21 @@ x86_gnu_fallback_frame_state
 {
   struct handler_args {
 int signo;
-int sigcode;
-struct sigcontext *scp;
+union
+  {
+   struct
+ {
+   long int sigcode;
+   struct sigcontext *scp;
+ } legacy;
+   struct
+ {
+   siginfo_t *siginfop;
+   ucontext_t *uctxp;
+ } posix;
+  };
   } *handler_args;
-  struct sigcontext *scp;
+  long int sigcode;
   unsigned long usp;
 
 /*
@@ -75,29 +86,52 @@ x86_gnu_fallback_frame_state
 return _URC_END_OF_STACK;
 
   handler_args = context->cfa;
-  scp = handler_args->scp;
-  usp = scp->sc_uesp;
+  sigcode = handler_args->legacy.sigcode;
+  if (sigcode < 4096)
+{
+  /* This cannot be a SIGINFO pointer, assume legacy.  */
+  struct sigcontext *scp = handler_args->legacy.scp;
+  usp = scp->sc_uesp;
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+}
+  else
+{
+  /* This is not a valid sigcode, assume SIGINFO.  */
+  ucontext_t *uctxp = handler_args->posix.uctxp;
+  gregset_t *gregset = &uctxp->uc_mcontext.gregs;
+  usp = (*gregset)[REG_UESP];
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&(*gregset)[REG_EAX] - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&(*gregset)[REG_ECX] - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&(*gregset)[REG_EDX] - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&(*gregset)[REG_EBX] - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&(*gregset)[REG_EBP] - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&(*gregset)[REG_ESI] - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&(*gregset)[REG_EDI] - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&(*gregset)[REG_EIP] - usp;
+}
 
   fs->regs.cfa_how = CFA_REG_OFFSET;
   fs->regs.cfa_reg = 4;
   fs->regs.cfa_offset = usp - (unsigned long) context->cfa;
 
   fs->regs.reg[0].how = REG_SAVED_OFFSET;
-  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
   fs->regs.reg[1].how = REG_SAVED_OFFSET;
-  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
   fs->regs.reg[2].how = REG_SAVED_OFFSET;
-  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
   fs->regs.reg[3].how = REG_SAVED_OFFSET;
-  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
   fs->regs.reg[5].how = REG_SAVED_OFFSET;
-  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
   fs->regs.reg[6].how = REG_SAVED_OFFSET;
-  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
   fs->regs.reg[7].how = REG_SAVED_OFFSET;
-  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
   fs->regs.reg[8].how = REG_SAVED_OFFSET;
-  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+
   fs->retaddr_column = 8;
   fs->signal_frame = 1;
 

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Almudena Garcia, le lun. 21 déc. 2020 01:05:29 +0100, a ecrit:
> What do you need exactly?

I need gcc people to apply it.

> How can we test It?

The answer would be lengthy. Basically recompile gcc with it, write or
find a program that uses it, and check that it works.

But I have already done that simply by letting glibc use ifunc, and it
does work, so there is nothing more to be done on the Hurd developers'
side.

Samuel

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Ping?

Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
> 
> 2020-11-08  Samuel Thibault  
> 
>   gcc/
>   * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
>   target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu).
> ---
>  gcc/config.gcc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b42ebc4e5be..a347c2cec7c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3538,7 +3538,9 @@ esac
>  case ${target} in
>  *-*-linux*android*|*-*-linux*uclibc*|*-*-linux*musl*)
>  ;;
> -*-*-linux*)
> +*-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> +;;
> +*-*-linux* | *-*-gnu*)
>   case ${target} in
>   aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | 
> x86_64-*)
>   default_gnu_indirect_function=yes
> -- 
> 2.20.1
> 

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Ping?

Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
> 
> 2020-11-08  Samuel Thibault  
> 
>   gcc/
>   * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
>   target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu).
> ---
>  gcc/config.gcc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b42ebc4e5be..a347c2cec7c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3538,7 +3538,9 @@ esac
>  case ${target} in
>  *-*-linux*android*|*-*-linux*uclibc*|*-*-linux*musl*)
>  ;;
> -*-*-linux*)
> +*-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> +;;
> +*-*-linux* | *-*-gnu*)
>   case ${target} in
>   aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | 
> x86_64-*)
>   default_gnu_indirect_function=yes
> -- 
> 2.20.1

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Ping?

I was able to pass glibc's complete ifunc tests with no problem.

Samuel

Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
> 
> 2020-11-08  Samuel Thibault  
> 
>   gcc/
>   * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
>   target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu).
> ---
>  gcc/config.gcc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b42ebc4e5be..a347c2cec7c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3538,7 +3538,9 @@ esac
>  case ${target} in
>  *-*-linux*android*|*-*-linux*uclibc*|*-*-linux*musl*)
>  ;;
> -*-*-linux*)
> +*-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> +;;
> +*-*-linux* | *-*-gnu*)
>   case ${target} in
>   aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | 
> x86_64-*)
>   default_gnu_indirect_function=yes
> -- 
> 2.20.1
> 

-- 
Samuel
 bon comment on fait de l'investigation pour savoir qui est le vilain ?
 on débranche le routeur et on regarde qui s'affole
 -+- #ens-mim administre -+-

[PATCH] Hurd: Enable ifunc by default

[Samuel Thibault]

The binutils bugs seem to have been fixed.

2020-11-08  Samuel Thibault  

gcc/
* config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu).
---
 gcc/config.gcc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b42ebc4e5be..a347c2cec7c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3538,7 +3538,9 @@ esac
 case ${target} in
 *-*-linux*android*|*-*-linux*uclibc*|*-*-linux*musl*)
 ;;
-*-*-linux*)
+*-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
+;;
+*-*-linux* | *-*-gnu*)
case ${target} in
aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | 
x86_64-*)
default_gnu_indirect_function=yes
-- 
2.20.1

Re: [PATCH] hurd: libgcc unwinding support over signal trampolines

[Samuel Thibault]

Samuel Thibault, le lun. 08 juin 2020 13:36:55 +0200, a ecrit:
> Thomas Schwinge, le lun. 08 juin 2020 12:15:12 +0200, a ecrit:
> > Which GCC branches would you like this on?
> 
> Ideally it's be backported to gcc 9 and 10, so that it lands naturally
> in the Debian packages without having to bother doko.

Actually only gcc 10 would be needed.

Samuel

Re: [PATCH] hurd: libgcc unwinding support over signal trampolines

[Samuel Thibault]

Thomas Schwinge, le lun. 08 juin 2020 12:15:12 +0200, a ecrit:
> I'm not currently set up to test this, but I'll assume you have.

Sure :)

> Which GCC branches would you like this on?

Ideally it's be backported to gcc 9 and 10, so that it lands naturally
in the Debian packages without having to bother doko.

> Once we've got this in GCC, please then also cross-reference GCC's
> 'libgcc/config/i386/gnu-unwind.h' file in glibc's
> 'sysdeps/mach/hurd/i386/trampoline.c' file.

Ah, yes, I thought about it and forgot, will do.

Samuel

Re: [PATCH] hurd: libgcc unwinding support over signal trampolines

[Samuel Thibault]

Hello,

Any news on this?

Samuel

Samuel Thibault, le ven. 29 mai 2020 13:46:50 +0200, a ecrit:
> Hello,
> 
> libgcc is currently missing the support for unwinding over signal
> trampolines on GNU/Hurd. The attached patch implements it.
> 
> Samuel

> hurd: libgcc unwinding support over signal trampolines
> 
> * libgcc/config.host (md_unwind_header): Set to i386/gnu-unwind.h on
> i[34567]86-*-gnu*.
> * src/libgcc/config/i386/gnu-unwind.h: New file.
> 
> diff --git a/libgcc/config.host b/libgcc/config.host
> index 2cd42097167..044b34d53cc 100644
> --- a/libgcc/config.host
> +++ b/libgcc/config.host
> @@ -734,11 +734,17 @@ i[34567]86-*-linux*)
>   tm_file="${tm_file} i386/elf-lib.h"
>   md_unwind_header=i386/linux-unwind.h
>   ;;
> -i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-gnu* | 
> i[34567]86-*-kopensolaris*-gnu)
> +i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-kopensolaris*-gnu)
>   extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
> crtfastmath.o"
>   tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
> t-dfprules"
>   tm_file="${tm_file} i386/elf-lib.h"
>   ;;
> +i[34567]86-*-gnu*)
> + extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
> crtfastmath.o"
> + tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
> t-dfprules"
> + tm_file="${tm_file} i386/elf-lib.h"
> + md_unwind_header=i386/gnu-unwind.h
> + ;;
>  x86_64-*-linux*)
>   extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
> crtfastmath.o"
>   tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
> t-dfprules"
> diff --git a/src/libgcc/config/i386/gnu-unwind.h 
> b/src/libgcc/config/i386/gnu-unwind.h
> new file mode 100644
> index 000..db47f0ac1d4
> --- /dev/null
> +++ b/src/libgcc/config/i386/gnu-unwind.h
> @@ -0,0 +1,107 @@
> +/* DWARF2 EH unwinding support for GNU Hurd: x86.
> +   Copyright (C) 2020 Free Software Foundation, Inc.
> +   Contributed by Samuel Thibault 
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +Under Section 7 of GPL version 3, you are granted additional
> +permissions described in the GCC Runtime Library Exception, version
> +3.1, as published by the Free Software Foundation.
> +
> +You should have received a copy of the GNU General Public License and
> +a copy of the GCC Runtime Library Exception along with this program;
> +see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +<http://www.gnu.org/licenses/>.  */
> +
> +/* Do code reading to identify a signal frame, and set the frame
> +   state data appropriately.  See unwind-dw2.c for the structs. */
> +
> +#ifndef inhibit_libc
> +
> +#include 
> +
> +#define MD_FALLBACK_FRAME_STATE_FOR x86_gnu_fallback_frame_state
> +
> +static _Unwind_Reason_Code
> +x86_gnu_fallback_frame_state
> +(struct _Unwind_Context *context, _Unwind_FrameState *fs)
> +{
> +  struct handler_args {
> +int signo;
> +int sigcode;
> +struct sigcontext *scp;
> +  } *handler_args;
> +  struct sigcontext *scp;
> +  unsigned long usp;
> +
> +/*
> + * i386 sigtramp frame we are looking for follows.
> + * (see glibc/sysdeps/mach/hurd/i386/trampoline.c assembly)
> + *
> + * rpc_wait_trampoline:
> + *   0:  b8 e7 ff ff ff  mov$-25,%eax   mach_msg_trap
> + *   5:  9a 00 00 00 00 07 00lcall  $7,$0
> + *  12:  89 01   movl   %eax, (%ecx)
> + *  14:  89 dc   movl   %ebx, %esp  switch to signal 
> stack
> + *
> + * trampoline:
> + *  16:  ff d2   call   *%edx   call the handler 
> function
> + * RA HERE
> + *  18:  83 c4 0caddl   $12, %esp   pop its args
> + *  21:  c3  retreturn to 
> sigreturn
> + *
> + * firewall:
> + *  22:  f4  hlt
> + */
> +
> +  if (!(   *(unsigned int   *)(context->ra ) == 0xc30cc483
> +&& *(unsigned char  *)(context->ra +  4) ==   0xf4
> +
> +&& *(unsigned int   *)(context->ra -  

[PATCH] hurd: libgcc unwinding support over signal trampolines

[Samuel Thibault]

Hello,

libgcc is currently missing the support for unwinding over signal
trampolines on GNU/Hurd. The attached patch implements it.

Samuel
hurd: libgcc unwinding support over signal trampolines

* libgcc/config.host (md_unwind_header): Set to i386/gnu-unwind.h on
i[34567]86-*-gnu*.
* src/libgcc/config/i386/gnu-unwind.h: New file.

diff --git a/libgcc/config.host b/libgcc/config.host
index 2cd42097167..044b34d53cc 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -734,11 +734,17 @@ i[34567]86-*-linux*)
tm_file="${tm_file} i386/elf-lib.h"
md_unwind_header=i386/linux-unwind.h
;;
-i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-gnu* | 
i[34567]86-*-kopensolaris*-gnu)
+i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-kopensolaris*-gnu)
extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
crtfastmath.o"
tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
t-dfprules"
tm_file="${tm_file} i386/elf-lib.h"
;;
+i[34567]86-*-gnu*)
+   extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
crtfastmath.o"
+   tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
t-dfprules"
+   tm_file="${tm_file} i386/elf-lib.h"
+   md_unwind_header=i386/gnu-unwind.h
+   ;;
 x86_64-*-linux*)
extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
crtfastmath.o"
tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
t-dfprules"
diff --git a/src/libgcc/config/i386/gnu-unwind.h 
b/src/libgcc/config/i386/gnu-unwind.h
new file mode 100644
index 000..db47f0ac1d4
--- /dev/null
+++ b/src/libgcc/config/i386/gnu-unwind.h
@@ -0,0 +1,107 @@
+/* DWARF2 EH unwinding support for GNU Hurd: x86.
+   Copyright (C) 2020 Free Software Foundation, Inc.
+   Contributed by Samuel Thibault 
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+<http://www.gnu.org/licenses/>.  */
+
+/* Do code reading to identify a signal frame, and set the frame
+   state data appropriately.  See unwind-dw2.c for the structs. */
+
+#ifndef inhibit_libc
+
+#include 
+
+#define MD_FALLBACK_FRAME_STATE_FOR x86_gnu_fallback_frame_state
+
+static _Unwind_Reason_Code
+x86_gnu_fallback_frame_state
+(struct _Unwind_Context *context, _Unwind_FrameState *fs)
+{
+  struct handler_args {
+int signo;
+int sigcode;
+struct sigcontext *scp;
+  } *handler_args;
+  struct sigcontext *scp;
+  unsigned long usp;
+
+/*
+ * i386 sigtramp frame we are looking for follows.
+ * (see glibc/sysdeps/mach/hurd/i386/trampoline.c assembly)
+ *
+ * rpc_wait_trampoline:
+ *   0:b8 e7 ff ff ff  mov$-25,%eax   mach_msg_trap
+ *   5:9a 00 00 00 00 07 00lcall  $7,$0
+ *  12:89 01   movl   %eax, (%ecx)
+ *  14:89 dc   movl   %ebx, %esp  switch to signal 
stack
+ *
+ * trampoline:
+ *  16:ff d2   call   *%edx   call the handler 
function
+ * RA HERE
+ *  18:83 c4 0caddl   $12, %esp   pop its args
+ *  21:c3  retreturn to 
sigreturn
+ *
+ * firewall:
+ *  22:f4  hlt
+ */
+
+  if (!(   *(unsigned int   *)(context->ra ) == 0xc30cc483
+&& *(unsigned char  *)(context->ra +  4) ==   0xf4
+
+&& *(unsigned int   *)(context->ra -  4) == 0xd2ffdc89
+&& *(unsigned int   *)(context->ra -  8) == 0x01890007
+&& *(unsigned int   *)(context->ra - 12) == 0x
+&& *(unsigned int   *)(context->ra - 16) == 0x9aff
+&& *(unsigned short *)(context->ra - 18) == 0xe7b8))
+return _URC_END_OF_STACK;
+
+  handler_args = context->cfa;
+  scp = handler_args->scp;
+  usp = scp->sc_uesp;
+
+  fs->regs.cfa_how = CFA_REG_OFFSET;
+  fs->regs.cfa_reg = 4;
+  fs->regs.cfa_offset = usp - (unsigned long) context->cfa;
+
+  fs->regs.reg[0].how = REG_SAVED_OFFSET;
+  fs->regs.reg[0].loc.offset = (

Re: [PATCH] Updated patches for the port of gccgo to GNU/Hurd

[Samuel Thibault]

Svante Signell, le lun. 11 févr. 2019 12:10:21 +0100, a ecrit:
> WCONTINUED is not defined, I assume that WIFCONTINUED is not supported.
> 
> From waitpid(2):
> WCONTINUED (since Linux 2.6.10)
>also return if a stopped child has been resumed by delivery of SIGCONT.
> 
> @Samuel: more info?

git grep WCONTINUED .
yields nothing in hurd/proc, so it's probably just not supported yet
indeed.

> > > The third patch, src_libgo_testsuite_gotest.diff, is not strictly needed,
> > > but running the tests the annoying text is displayed: "ps: comm: Unknown
> > > format spec"
> > 
> > I get that "comm" doesn't work, but the change in that patch is simply
> > incorrect.  If you don't pass "comm", the "grep sleep" will never
> > succeed.  If there is no way to support this code on Hurd then we
> > should skip it, not put in a command that can never work.
> 
> OK, let's drop that part then.
> 
> @Samuel: more info?

arg0 can be used instead.

That said, we should implement comm since it's defined by posix, it's
probably a matter of duplicating the line "Arg0" in hurd/libps/spec.c

Samuel

Re: Update: Hurd port for gcc-7 go : 7.3.0-8+ for glibc 2.26+

[Samuel Thibault]

Hello,

Svante Signell, on sam. 10 mars 2018 19:33:35 +0100, wrote:
> Attached is the updated patch, src_libgo_build.diff, to build gccgo properly 
> on
> Debian GNU/Hurd on gcc-7 (7-7.3.0-{8,9,10}) again after the update of glibc to
> 2.26+

I have updated the gcc-7 package in Debian, thanks!

Samuel

Re: Hurd port for gcc-7 go PATCH 1-3(15)

[Samuel Thibault]

Hello,

Svante Signell, on lun. 06 nov. 2017 16:36:39 +0100, wrote:
> Another issue is that /proc/self/exe has to return an absolute path for the
> built program go-7 to execute properly. This is solved by a pending patch for
> glibc in Debian and will be available in the next upload of glibc-2.24.

FI, this was uploaded.

> Adding to this, the executable ./build/gotools/go does work displaying the 
> help
> text, but e.g. ./build/gotools/go env exits with a SIGILL: Illegal 
> instruction.

That seems to be still happening with the updated libc.

Samuel

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Samuel Thibault, on Mon 19 Dec 2016 00:25:35 +0100, wrote:
> as the attached patch does, which should really be applied or done
> any other way.

Or rather this patch, which makes it more like the test above.

Matthias, I'm committing this to Debian's gcc-6, along the other go
patches from Svante.

Samuel
Index: gcc/src/libgo/runtime/go-caller.c
===
--- gcc/src/libgo/runtime/go-caller.c   (révision 235086)
+++ gcc/src/libgo/runtime/go-caller.c   (copie de travail)
@@ -93,7 +93,7 @@
 argv[0] (http://gcc.gnu.org/PR61895).  It would be nice to
 have a better check for whether this file is the real
 executable.  */
-   if (stat (filename, &s) < 0 || s.st_size < 1024)
+   if (filename != NULL && (stat (filename, &s) < 0 || s.st_size < 1024))
filename = NULL;
 
   back_state = backtrace_create_state (filename, 1, error_callback, NULL);

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Hello,

Svante Signell, on Fri 25 Nov 2016 20:57:26 +0100, wrote:
> Another more annoying gnumch/hurd/glibc bug is that the
> built program go (go-6 in Debian) gets killed when executed from the
> shell vi path, but not when issued directly: /usr/bin/go-6 works fine.
>  go-6
> Segmentation fault (core dumped)

I've had a quick look by adding printfs in go-main.c and further to see
up to where it goes before crashing.  It crashes in

src/libgo/runtime/go-caller.c

in function __go_get_backtrace_state, inside the stat() call in:

if (__builtin_strchr (filename, '/') == NULL)
  filename = NULL;

if (stat (filename, &s) < 0 || s.st_size < 1024)
  filename = NULL;

filename of course doesn't start with '/' (it's argv[0]), and thus NULL
is passed to stat(). It happens that by luck on Linux this just returns
an EFAULT error, but that's sheer luck :) This should probably be turned
into e.g.:

if (!filename || stat (filename, &s) < 0 || s.st_size < 1024)
  filename = NULL;

as the attached patch does, which should really be applied or done
any other way.



Then calling go-6 brings this:

  fatal error: libbacktrace could not find executable to open

That's inside src/libbacktrace/fileline.c, the fileline_initialize
function, which tries the above filename (and thus fails), then
getexecname() (which is not implemented), then /proc/self/exe, which is
not implemented, then /proc/curproc/file which is even less implemented.

So here it'd be "just" a matter of implementing /proc/self/exe.

Samuel
Index: runtime/go-caller.c
===
--- runtime/go-caller.c (révision 235086)
+++ runtime/go-caller.c (copie de travail)
@@ -93,7 +93,7 @@
 argv[0] (http://gcc.gnu.org/PR61895).  It would be nice to
 have a better check for whether this file is the real
 executable.  */
-  if (stat (filename, &s) < 0 || s.st_size < 1024)
+  if (!filename || stat (filename, &s) < 0 || s.st_size < 1024)
filename = NULL;
 
   back_state = backtrace_create_state (filename, 1, error_callback, NULL);

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Svante Signell, on Wed 07 Dec 2016 15:32:31 +0100, wrote:
> On Wed, 2016-12-07 at 15:08 +0100, Samuel Thibault wrote:
> > Ok, but then I'd say move the function which change to a separate file,
> > so that the other functions are kept shared.
> > Otherwise it'll be tedious to maintain.
> 
> One problem is the file go/syscall/libcall_posix-1.go, derived
> from go/syscall/libcall_posix.go but _removing_ four function definitions:
> mount, madvise, mlockall and munlockall.

That's not a problem: move them out to another file, and include that
file in the non-gnu case, but do not include that file in the gnu case.

Actually it's even odd to see mount among them, it's not a standard
posix interface.

Samuel

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Svante Signell, on Wed 07 Dec 2016 14:52:35 +0100, wrote:
> Since go does not have a preprocessor allowing conditional code paths this is
> how it should be done (and as I did):
> http://blog.ralch.com/tutorial/golang-conditional-compilation/

Ok, but then I'd say move the function which change to a separate file,
so that the other functions are kept shared.
Otherwise it'll be tedious to maintain.

Samuel

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Svante Signell, on Sun 27 Nov 2016 18:17:17 +0100, wrote:
> On Sun, 2016-11-27 at 18:02 +0100, Samuel Thibault wrote:
> > > But as you wish, an updated patch is attached.
> > 
> >  _Bool
> >  Continued (uint32_t *w)
> >  {
> > +#ifndef WCONTINUED
> > +  *w = 0;
> > +  return 0;
> > +#else
> >    return WIFCONTINUED (*w) != 0;
> > +#endif
> >  }
> > 
> > Err, recheck the semantic of WCONTINUED again, it doesn't modify its
> > parameter, it just tests its value.
> > 
> > Do as I said, just return 0.
> 
> No I can't the compiler complains about an unused variable. Maybe
> adding an __attribute__((unused)) to the function header?

For instance.  See how it is done in the rest of the code.

> > > This is for upstream to decide.
> > 
> > I'm just afraid they'd just frown on the code submission and not take
> > the time to explain how they want it to look like if we don't raise
> > the
> > discussion ourselves.
> > 
> 
> Should we propose these changes upstream? Or do you mean something
> else? 

I mean proposing explicitly to upstream, yes, so they don't have to
take the time to explain.

> > Then ask upstream how they think it can and should be done.
> 
> Upstream would be Ian Lance Taylor, right?

I don't know.

> > > > > -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum
> > > > > libgo.log
> > > > > +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
> > > > 
> > > > This seems unrelated?
> > > > 
> > > No, this is not unrelated: With this patch you can
> > > make -C build/i686-gnu/libgo clean
> > > make -C build/i686-gnu/libgo
> > > to rebuild libgo. Otherwise libcalls.go is not regenerated,
> > > mksysinfo.sh is not run etc. 
> > 
> > That's still unrelated to the matter here: porting go to
> > GNU/Hurd.  It
> > looks like a bug fix which is completely independant from GNU/Hurd.
> 
> Yes it is not Hurd-related. Maybe this should be filed as a separate
> bug. To gcc upstream directly?

Yes.

> > > > We could rather just implement the comm field in ps, AIUI it's
> > > > just an alias for the command field.
> > > 
> > > Your choice. When implemented this patch wouldn't bee needed.
> > 
> > Then please do implement it :)
> 
> Sorry, I need help for doing this. Any other Hurd developer listening?

See spec_abbrevs in utils/ps.c, I guess it's a matter of adding
{"Comm=args"} in the list.

Samuel

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Hello,

Svante Signell, on Sun 27 Nov 2016 17:33:52 +0100, wrote:
> > > Index: gcc-6-6.2.1-4.1/src/libgo/go/syscall/wait.c
> > > ===
> > > --- gcc-6-6.2.1-4.1.orig/src/libgo/go/syscall/wait.c
> > > +++ gcc-6-6.2.1-4.1/src/libgo/go/syscall/wait.c
> > > @@ -8,6 +8,9 @@
> > > OS-independent.  */
> > >  
> > >  #include 
> > > +#ifndef WCONTINUED
> > > +#define WCONTINUED 0
> > > +#endif
> > >  #include 
> > >  
> > >  #include "runtime.h"
> > 
> > That looks odd at best: WCONTINUED can't be defined at this place
> > anyway, so it'll get defined to 0. Fortunately the sys/wait.h
> > definition
> > would override this. But then wait.c will define something which does
> > not make sense since WCONTINUED is not implemented. Better use #ifdef
> > WCONTINUED inside the Continued function, to always return 0 when
> > it's
> > not defined.
> > 
> 
> I've been implementing that version too, with no visible differences.

"no visible differences" doesn't mean there is none :)

> But as you wish, an updated patch is attached.

 _Bool
 Continued (uint32_t *w)
 {
+#ifndef WCONTINUED
+  *w = 0;
+  return 0;
+#else
   return WIFCONTINUED (*w) != 0;
+#endif
 }

Err, recheck the semantic of WCONTINUED again, it doesn't modify its
parameter, it just tests its value.

Do as I said, just return 0.



> This is for upstream to decide.

I'm just afraid they'd just frown on the code submission and not take
the time to explain how they want it to look like if we don't raise the
discussion ourselves.



> > And
> > src_libgo_go_syscall_syscall_gnu_test.go: New file:
> >   Define Type and Whence as 32bit in syscall.Flock_t
> > 
> > Again, you'll probably have to discuss with upstream to see how they
> > prefer to make it configurable rather than forking the whole file.
> >
> 
> I tried to patch the syscall_unix_test.go file, but did not succeed. 
> Definitely if runtime.GOOS == "GNU" ... else ... or switch runtime.GOOS
> ... does not work. The compiler sees all code and complains, also the
> else part of the code :( Therefore I created a new file.

Then ask upstream how they think it can and should be done.



> > > @@ -4431,7 +4505,7 @@ mostlyclean-local:
> > >   find . -name '*-testsum' -print | xargs rm -f
> > >   find . -name '*-testlog' -print | xargs rm -f
> > >  
> > > -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum libgo.log
> > > +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
> > 
> > This seems unrelated?
> > 
> No, this is not unrelated: With this patch you can
> make -C build/i686-gnu/libgo clean
> make -C build/i686-gnu/libgo
> to rebuild libgo. Otherwise libcalls.go is not regenerated,
> mksysinfo.sh is not run etc. 

That's still unrelated to the matter here: porting go to GNU/Hurd.  It
looks like a bug fix which is completely independant from GNU/Hurd.

> > Svante Signell, on Fri 25 Nov 2016 21:04:58 +0100, wrote:
> > > * src_libgo_runtime_netpoll.goc.diff: Fix restricted word bug.
> > >   Rename variable errno to errno1.
> > > * src_libgo_go_os_os_test.go.diff: Allow EFBIG return code to big
> > > seeks.
> > > * src_libgo_go_syscall_syscall_gnu_test.go: New file:
> > >   Define Type and Whence as 32bit in syscall.Flock_t
> > > * src_libgo_testsuite_gotest.diff: Remove comm option for ps -o.
> > > * add-gnu-to-libgo-headers.diff:
> > >   Add gnu to +build entry in file headers included in the build.
> > >   FIXME:  
> > 
> > I can't find these in the patches you sent.
> 
> It is in the last mail: patch 19-23(23)

Ah, sorry, mutt had pasted the content of the attached files without
putting the file names.

> > > Index: gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> > > ===
> > > --- gcc-6-6.2.1-4.1.orig/src/libgo/testsuite/gotest
> > > +++ gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> > > @@ -618,7 +618,11 @@ xno)
> > >   wait $pid
> > >   status=$?
> > >   if ! test -f gotest-timeout; then
> > > - sleeppid=`ps -o pid,ppid,comm | grep "
> > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'`
> > > + if test "$goos" = "gnu"; then
> > > + sleeppid=`ps -o pid,ppid | grep "
> > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'`
> > > + else
> > > + sleeppid=`ps -o pid,ppid,comm | grep "
> > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'`
> > > + fi
> > >   kill $alarmpid
> > >   wait $alarmpid
> > >   if test "$sleeppid" != ""; then
> > 
> > 
> > We could rather just implement the comm field in ps, AIUI it's just
> > an
> > alias for the command field.
> 
> Your choice. When implemented this patch wouldn't bee needed.

Then please do implement it :)

Samuel

Re: Please include ada-hurd.diff upstream (try2)

[Samuel Thibault]

Svante Signell, on Wed 04 May 2016 23:25:28 +0200, wrote:
> On Wed, 2016-05-04 at 23:06 +0200, Samuel Thibault wrote:
> > Svante Signell, on Wed 04 May 2016 19:43:27 +0200, wrote:
> > > May I comment on Debian way of apt-get source gcc-*: Doing that
> > > does
> > > not unpack the sources, neither does it apply the patches, you have
> > > to
> > > unpack and patch before you can change sources and update patches.
> > > Iv'e
> > > patched the sources several times and still find that the updated
> > > patches are not included in the next build. Really confusing.
> > 
> > Did you read debian/README.source?
> 
> Now I have read it, but still cannot find a convincing reason for doing
> things this way, sorry! Matthias, why? There should be very strong
> arguments for the present procedure.

See rules.patch. You can't get this behavior with the simple dpkg
patching.

Samuel

Re: Please include ada-hurd.diff upstream (try2)

[Samuel Thibault]

Svante Signell, on Wed 04 May 2016 19:43:27 +0200, wrote:
> May I comment on Debian way of apt-get source gcc-*: Doing that does
> not unpack the sources, neither does it apply the patches, you have to
> unpack and patch before you can change sources and update patches. Iv'e
> patched the sources several times and still find that the updated
> patches are not included in the next build. Really confusing.

Did you read debian/README.source?

Samuel

Re: Please include ada-hurd.diff upstream (try2)

[Samuel Thibault]

Samuel Thibault, on Wed 04 May 2016 17:29:48 +0200, wrote:
> The gcc-6 build failed. I see that one of the change is:
> 
> -   --  From: /usr/include/unistd.h __getpagesize or getpagesize??
> -   function Get_Page_Size return int;
> +   --  From: /usr/include/i386-gnu/bits/shm.h __getpagesize or getpagesize??
> +   function Get_Page_Size return size_t;
> +   function Get_Page_Size return Address;
> 
> Why using size_t and Address?  Other OSes use int, and the prototype for
> getpagesize is returning int.
> 
> Also, don't use the __ versions of the glibc functions, they are
> internal aliases, the API is without __.

I.e. the proposed change below.

Samuel


2016-05-04  Samuel Thibault  

* s-osinte-gnu.ads: Make Get_Page_Size return int, and make it use
getpagesize instead of __getpagesize.

--- a/src/gcc/ada/s-osinte-gnu.ads
+++ b/src/gcc/ada/s-osinte-gnu.ads
@@ -344,10 +344,9 @@ package System.OS_Interface is
--  returns the stack base of the specified thread. Only call this function
--  when Stack_Base_Available is True.
 
-   --  From: /usr/include/i386-gnu/bits/shm.h __getpagesize or getpagesize??
-   function Get_Page_Size return size_t;
-   function Get_Page_Size return Address;
-   pragma Import (C, Get_Page_Size, "__getpagesize");
+   --  From: /usr/include/i386-gnu/bits/shm.h
+   function Get_Page_Size return int;
+   pragma Import (C, Get_Page_Size, "getpagesize");
--  Returns the size of a page
 
--  From /usr/include/i386-gnu/bits/mman.h

Re: Please include ada-hurd.diff upstream (try2)

[Samuel Thibault]

Hello Svante,

The gcc-6 build failed. I see that one of the change is:

-   --  From: /usr/include/unistd.h __getpagesize or getpagesize??
-   function Get_Page_Size return int;
+   --  From: /usr/include/i386-gnu/bits/shm.h __getpagesize or getpagesize??
+   function Get_Page_Size return size_t;
+   function Get_Page_Size return Address;

Why using size_t and Address?  Other OSes use int, and the prototype for
getpagesize is returning int.

Also, don't use the __ versions of the glibc functions, they are
internal aliases, the API is without __.

Samuel

Re: [PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

Hello,

Thomas Schwinge, on Tue 29 Mar 2016 23:19:09 +0200, wrote:
> On Wed, 24 Feb 2016 23:46:36 +0100, I wrote:
> > On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault 
> >  wrote:
> > > On Linux, -p and -pg do not make gcc link against libc_p.a, only
> > > -profile does (as documented in r11246), and thus people expect -p
> > 
> > (Yo, 20 years ago...)
> > 
> > > and -pg to work without libc_p.a installed (it is actually even not
> > > available any more in Debian).  We should thus rather make the Hurd port
> > > do the same to avoid build failures.
> > 
> > Conceptually, ACK.
> 
> > I'm now testing the following patch:
> 
> Now committed in r234535:

Groovy :)

Could you also commit to gcc 5 branches so we get it in Debian without
having to poke Doko?

Samuel

Re: [PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

Samuel Thibault, on Thu 25 Feb 2016 00:18:21 +0100, wrote:
> Thomas Schwinge, on Wed 24 Feb 2016 23:46:36 +0100, wrote:
> > I guess getting -D_REENTRANT for -pthread won't do us any harm?
> 
> It won't.

(Actually we've been using this in Debian for a long time).

Samuel

Re: [PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

Thomas Schwinge, on Wed 24 Feb 2016 23:46:36 +0100, wrote:
> I guess getting -D_REENTRANT for -pthread won't do us any harm?

It won't.

> > --- gcc/config/i386/gnu.h.orig  2015-09-17 21:41:13.0 +
> > +++ gcc/config/i386/gnu.h   2015-09-17 23:03:57.0 +
> > @@ -27,11 +27,11 @@
> >  #undef STARTFILE_SPEC
> >  #if defined HAVE_LD_PIE
> >  #define STARTFILE_SPEC \
> > -  "%{!shared: 
> > %{pg|p|profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
> > +  "%{!shared: 
> > %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
> >  \
> > crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> >  #else
> >  #define STARTFILE_SPEC \
> > -  "%{!shared: %{pg|p|profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
> > +  "%{!shared: 
> > %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
> > crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> >  #endif
> 
> I think I understand what you're trying to do (avoid gcrt0.o being used
> for -pg or -p, and instead use gcrt1.o),

Yes.

> Likewise, for -pg or -p, I would assume that we
> still need gcrt0.o for static linking, and gcrt1.o for dynamic linking.

Mmm, probably indeed.

> -  "%{!shared: 
> %{pg|p|profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
> +  "%{!shared: 
> %{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
>  \

Yes, that looks reasonable.

Samuel

Re: [PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

Ping?

Samuel Thibault, on Sun 11 Oct 2015 20:29:10 +0200, wrote:
> Ping?
> 
> (I don't have commit access)
> 
> Samuel Thibault, le Sat 19 Sep 2015 14:00:23 +0200, a écrit :
> > On Linux, -p and -pg do not make gcc link against libc_p.a, only
> > -profile does (as documented in r11246), and thus people expect -p
> > and -pg to work without libc_p.a installed (it is actually even not
> > available any more in Debian).  We should thus rather make the Hurd port
> > do the same to avoid build failures.
> > 
> > Samuel
> > 
> > * gcc/config/gnu.h (LIB_SPEC) [-p|-pg]: Link with -lc instead of -lc_p.
> > * gcc/config/i386/gnu.h (STARTFILE_SPEC) [-p|-pg]: Use gcrt1.o
> > instead of gcrt0.o.
> > 
> > --- gcc/config/gnu.h.orig   2015-09-16 00:43:09.785570853 +0200
> > +++ gcc/config/gnu.h2015-09-16 00:43:12.513550418 +0200
> > @@ -25,7 +25,7 @@
> >  
> >  /* Default C library spec.  */
> >  #undef LIB_SPEC
> > -#define LIB_SPEC "%{pthread:-lpthread} %{pg|p|profile:-lc_p;:-lc}"
> > +#define LIB_SPEC "%{pthread:-lpthread} %{profile:-lc_p;:-lc}"
> >  
> >  #undef GNU_USER_TARGET_OS_CPP_BUILTINS
> >  #define GNU_USER_TARGET_OS_CPP_BUILTINS()  \
> > --- gcc/config/i386/gnu.h.orig  2015-09-17 21:41:13.0 +
> > +++ gcc/config/i386/gnu.h   2015-09-17 23:03:57.0 +
> > @@ -27,11 +27,11 @@
> >  #undef STARTFILE_SPEC
> >  #if defined HAVE_LD_PIE
> >  #define STARTFILE_SPEC \
> > -  "%{!shared: 
> > %{pg|p|profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
> > +  "%{!shared: 
> > %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
> >  \
> > crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> >  #else
> >  #define STARTFILE_SPEC \
> > -  "%{!shared: %{pg|p|profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
> > +  "%{!shared: 
> > %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
> > crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
> >  #endif
> >  

-- 
Samuel
 hiri, le cri ici, c des marrants
 j'ai un rep ".uglyhackdirectorywithoutacls" ds mon home
 -+- #ens-mim en stage -+-

Re: [PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

Ping?

(I don't have commit access)

Samuel Thibault, le Sat 19 Sep 2015 14:00:23 +0200, a écrit :
> On Linux, -p and -pg do not make gcc link against libc_p.a, only
> -profile does (as documented in r11246), and thus people expect -p
> and -pg to work without libc_p.a installed (it is actually even not
> available any more in Debian).  We should thus rather make the Hurd port
> do the same to avoid build failures.
> 
> Samuel
> 
>   * gcc/config/gnu.h (LIB_SPEC) [-p|-pg]: Link with -lc instead of -lc_p.
> * gcc/config/i386/gnu.h (STARTFILE_SPEC) [-p|-pg]: Use gcrt1.o
> instead of gcrt0.o.
> 
> --- gcc/config/gnu.h.orig 2015-09-16 00:43:09.785570853 +0200
> +++ gcc/config/gnu.h  2015-09-16 00:43:12.513550418 +0200
> @@ -25,7 +25,7 @@
>  
>  /* Default C library spec.  */
>  #undef LIB_SPEC
> -#define LIB_SPEC "%{pthread:-lpthread} %{pg|p|profile:-lc_p;:-lc}"
> +#define LIB_SPEC "%{pthread:-lpthread} %{profile:-lc_p;:-lc}"
>  
>  #undef GNU_USER_TARGET_OS_CPP_BUILTINS
>  #define GNU_USER_TARGET_OS_CPP_BUILTINS()\
> --- gcc/config/i386/gnu.h.orig2015-09-17 21:41:13.0 +
> +++ gcc/config/i386/gnu.h 2015-09-17 23:03:57.0 +
> @@ -27,11 +27,11 @@
>  #undef   STARTFILE_SPEC
>  #if defined HAVE_LD_PIE
>  #define STARTFILE_SPEC \
> -  "%{!shared: 
> %{pg|p|profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
> +  "%{!shared: 
> %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
> crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
>  #else
>  #define STARTFILE_SPEC \
> -  "%{!shared: %{pg|p|profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
> +  "%{!shared: %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} 
> \
> crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
>  #endif
>  

Re: [PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

Ping?

Samuel Thibault, le Sat 19 Sep 2015 14:00:23 +0200, a écrit :
> On Linux, -p and -pg do not make gcc link against libc_p.a, only
> -profile does (as documented in r11246), and thus people expect -p
> and -pg to work without libc_p.a installed (it is actually even not
> available any more in Debian).  We should thus rather make the Hurd port
> do the same to avoid build failures.
> 
> Samuel
> 
>   * gcc/config/gnu.h (LIB_SPEC) [-p|-pg]: Link with -lc instead of -lc_p.
> * gcc/config/i386/gnu.h (STARTFILE_SPEC) [-p|-pg]: Use gcrt1.o
> instead of gcrt0.o.
> 
> --- gcc/config/gnu.h.orig 2015-09-16 00:43:09.785570853 +0200
> +++ gcc/config/gnu.h  2015-09-16 00:43:12.513550418 +0200
> @@ -25,7 +25,7 @@
>  
>  /* Default C library spec.  */
>  #undef LIB_SPEC
> -#define LIB_SPEC "%{pthread:-lpthread} %{pg|p|profile:-lc_p;:-lc}"
> +#define LIB_SPEC "%{pthread:-lpthread} %{profile:-lc_p;:-lc}"
>  
>  #undef GNU_USER_TARGET_OS_CPP_BUILTINS
>  #define GNU_USER_TARGET_OS_CPP_BUILTINS()\
> --- gcc/config/i386/gnu.h.orig2015-09-17 21:41:13.0 +
> +++ gcc/config/i386/gnu.h 2015-09-17 23:03:57.0 +
> @@ -27,11 +27,11 @@
>  #undef   STARTFILE_SPEC
>  #if defined HAVE_LD_PIE
>  #define STARTFILE_SPEC \
> -  "%{!shared: 
> %{pg|p|profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
> +  "%{!shared: 
> %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
> crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
>  #else
>  #define STARTFILE_SPEC \
> -  "%{!shared: %{pg|p|profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
> +  "%{!shared: %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} 
> \
> crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
>  #endif
>  

-- 
Samuel
Hi ! I'm a .signature virus ! Copy me into your ~/.signature, please !

[PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

On Linux, -p and -pg do not make gcc link against libc_p.a, only
-profile does (as documented in r11246), and thus people expect -p
and -pg to work without libc_p.a installed (it is actually even not
available any more in Debian).  We should thus rather make the Hurd port
do the same to avoid build failures.

Samuel

* gcc/config/gnu.h (LIB_SPEC) [-p|-pg]: Link with -lc instead of -lc_p.
* gcc/config/i386/gnu.h (STARTFILE_SPEC) [-p|-pg]: Use gcrt1.o
instead of gcrt0.o.

--- gcc/config/gnu.h.orig   2015-09-16 00:43:09.785570853 +0200
+++ gcc/config/gnu.h2015-09-16 00:43:12.513550418 +0200
@@ -25,7 +25,7 @@
 
 /* Default C library spec.  */
 #undef LIB_SPEC
-#define LIB_SPEC "%{pthread:-lpthread} %{pg|p|profile:-lc_p;:-lc}"
+#define LIB_SPEC "%{pthread:-lpthread} %{profile:-lc_p;:-lc}"
 
 #undef GNU_USER_TARGET_OS_CPP_BUILTINS
 #define GNU_USER_TARGET_OS_CPP_BUILTINS()  \
--- gcc/config/i386/gnu.h.orig  2015-09-17 21:41:13.0 +
+++ gcc/config/i386/gnu.h   2015-09-17 23:03:57.0 +
@@ -27,11 +27,11 @@
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
+  "%{!shared: 
%{pg|p:gcrt1.o%s;profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
-  "%{!shared: %{pg|p|profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
+  "%{!shared: %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
 #endif
 

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Samuel Thibault]

Svante Signell, le Wed 21 May 2014 11:42:30 +0200, a écrit :
> On Wed, 2014-05-21 at 11:27 +0200, Samuel Thibault wrote:
> > Guaranteeing long term support *is* about taking up the work of checking
> > periodically that the port works fine.  If anybody does it, then it's
> > fine.  If nobody does it, then the port will be dropped.  It's as simple
> > as this.  You're welcome for doing it of course.
> 
> I've been doing this since 2012 and I said I could continue doing it,
> but that did not seem to be sufficient.

I must have missed an episode then.  The only context I have is

“
That's actually the biggest concern when people submit a new port: they
submit it, get it approved, commit it and then are no longer available
for any maintenance when these files need to be updated/become outdated/
no longer compile or run.
”

Does it mean it is a lack of reviewer/commiter which is pointed out?

> Well dropping patches not upstream is a nop, right?

Yes, sure.

> > > >  I guess that's not what you want, so I don't know what you meant.
> > > 
> > > If that happens -> means if the port is bitrotting for a long time just
> > > remove support upstream. We were talking upstream here, not Debian ...
> > 
> > What support?  I really don't undestand what you mean.
> 
> Remove support for a language for bitrotting architectures (obsolete
> ports) like is done for old Solaris 9 (*-*-solaris2.9)
> http://www.gnu.org/software/gcc/gcc-4.9/changes.html

I fully understand that. What I don't understand is what you said
initially:

“
> > > > > (Of course it can at least run on Debian systems if/when accepted.)
> > > > 
> > > > Sure, but will it continue working on the long term?  That's the concern
> > > > of upstream.
> 
> If that happens why not just remove support for that architecture? The
> same happens for plain C, C++, etc on outdated architectures.
”

Again, what I understand from your "why not just remove support for that
architecture" is that you propose to remove the Hurd port.  I obviously
guess that it's not what you meant, so I don't understand what you
actually meant.

Samuel

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Samuel Thibault]

Svante Signell, le Wed 21 May 2014 11:22:44 +0200, a écrit :
> On Wed, 2014-05-21 at 10:47 +0200, Samuel Thibault wrote:
> > Svante Signell, le Wed 21 May 2014 10:40:37 +0200, a écrit :
> > > > > What kind of person do you have to be to be accepted, a GNU/Hurd
> > > > > developer or a GNU/Ada developer having a gnu.org account?
> > > > 
> > > > Nothing special, just like for contributing to any opensource project;
> > > > just someone who checks from times to times (in particular before
> > > > releases) that the port works fine, and submit patches if needed.
> > > 
> > > I've been working on the Hurd port of gnat since late 2011 including the
> > > toughest: bootstrapping, does that count?
> > 
> > Count for what?
> > 
> > Opensource is about patches correctness, not people fame.
> > 
> > If anybody, whoever he is, takes up the work and produces correct
> > patches, then they'll be applied.  It's as simple as this.
> 
> In this case if long term support can be guaranteed, yes!

I don't understand what you mean.

Guaranteeing long term support *is* about taking up the work of checking
periodically that the port works fine.  If anybody does it, then it's
fine.  If nobody does it, then the port will be dropped.  It's as simple
as this.  You're welcome for doing it of course.

> > > > > > > (Of course it can at least run on Debian systems if/when 
> > > > > > > accepted.)
> > > > > > 
> > > > > > Sure, but will it continue working on the long term?  That's the 
> > > > > > concern
> > > > > > of upstream.
> > > 
> > > If that happens why not just remove support for that architecture? The
> > > same happens for plain C, C++, etc on outdated architectures.
> > 
> > Uh?  I'm not sure what you mean here.  What I understand is "why not
> > remove support for GNU/Hurd?" which'd mean dropping your patches.
> 
> How can they be removed, they are not upstream yet?

I even less understand what you meant then.

> >  I guess that's not what you want, so I don't know what you meant.
> 
> If that happens -> means if the port is bitrotting for a long time just
> remove support upstream. We were talking upstream here, not Debian ...

What support?  I really don't undestand what you mean.

Samuel

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Samuel Thibault]

Svante Signell, le Wed 21 May 2014 10:44:54 +0200, a écrit :
> On Wed, 2014-05-21 at 10:33 +0200, Arnaud Charlet wrote:
> > > > I think the majority of work has bee done, Now that patch will change
> > > > slightly for every missing feature added to Hurd.
> > > 
> > > Then it's all good, it's a matter of what I said above.
> > 
> > Don't forget also the part where general changes are done in GNAT which
> > require update to target specific files: these typically require someone
> > to regularly test each port to detect any missing update, and report/fix
> > them, even if GNU/Hurd hasn't changed itself.
> 
> With the help from the dabian-ada people, especially Ludovic Brenta,
> gnat has been running on GNU/Hurd in Debian since gcc/gnat-4.6.3.

Then it's all good.  Just say that you wish to continue maintaining
things like this, and upstream will be happy.

Samuel

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Samuel Thibault]

Svante Signell, le Wed 21 May 2014 10:40:37 +0200, a écrit :
> > > What kind of person do you have to be to be accepted, a GNU/Hurd
> > > developer or a GNU/Ada developer having a gnu.org account?
> > 
> > Nothing special, just like for contributing to any opensource project;
> > just someone who checks from times to times (in particular before
> > releases) that the port works fine, and submit patches if needed.
> 
> I've been working on the Hurd port of gnat since late 2011 including the
> toughest: bootstrapping, does that count?

Count for what?

Opensource is about patches correctness, not people fame.

If anybody, whoever he is, takes up the work and produces correct
patches, then they'll be applied.  It's as simple as this.

> > > > > (Of course it can at least run on Debian systems if/when accepted.)
> > > > 
> > > > Sure, but will it continue working on the long term?  That's the concern
> > > > of upstream.
> 
> If that happens why not just remove support for that architecture? The
> same happens for plain C, C++, etc on outdated architectures.

Uh?  I'm not sure what you mean here.  What I understand is "why not
remove support for GNU/Hurd?" which'd mean dropping your patches.  I
guess that's not what you want, so I don't know what you meant.

Samuel

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Samuel Thibault]

Arnaud Charlet, le Wed 21 May 2014 10:33:31 +0200, a écrit :
> > > I think the majority of work has bee done, Now that patch will change
> > > slightly for every missing feature added to Hurd.
> > 
> > Then it's all good, it's a matter of what I said above.
> 
> Don't forget also the part where general changes are done in GNAT which
> require update to target specific files: these typically require someone
> to regularly test each port to detect any missing update, and report/fix
> them, even if GNU/Hurd hasn't changed itself.

Ah, I read what Svante said too fast.  I thought he was talking about
"every feature added to gnat".  I sure agree with Arnaud.

Samuel

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Samuel Thibault]

Svante Signell, le Wed 21 May 2014 10:20:16 +0200, a écrit :
> On Wed, 2014-05-21 at 10:03 +0200, Samuel Thibault wrote:
> > Svante Signell, le Wed 21 May 2014 09:49:59 +0200, a écrit :
> > > Thomas and Samuel: It looks like upstream don't accept patches unless a
> > > Hurd port maintainer commits to it. What's the use of all this job?
> > 
> > Well, simply to keep the changes working.  That is not surprising at all.
> 
> I might not be interested any longer with this kind of requirements.

Well, then somebody else will have to if we want to keep the gnat port
alive.  I for myself don't really have time to do it.

> What kind of person do you have to be to be accepted, a GNU/Hurd
> developer or a GNU/Ada developer having a gnu.org account?

Nothing special, just like for contributing to any opensource project;
just someone who checks from times to times (in particular before
releases) that the port works fine, and submit patches if needed.

> > > (Of course it can at least run on Debian systems if/when accepted.)
> > 
> > Sure, but will it continue working on the long term?  That's the concern
> > of upstream.
> 
> I think the majority of work has bee done, Now that patch will change
> slightly for every missing feature added to Hurd.

Then it's all good, it's a matter of what I said above.

> > In principle it's just a matter of fixing just a few things over the
> > coming versions.  But someone has to do it, otherwise the port will just
> > die.
> 
> I wonder ho the kfreebsd people managed to get accepted upstream?

Simply by having someone making sure things are going right, I guess.

Samuel

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Samuel Thibault]

Svante Signell, le Wed 21 May 2014 09:49:59 +0200, a écrit :
> Thomas and Samuel: It looks like upstream don't accept patches unless a
> Hurd port maintainer commits to it. What's the use of all this job?

Well, simply to keep the changes working.  That is not surprising at all.

> (Of course it can at least run on Debian systems if/when accepted.)

Sure, but will it continue working on the long term?  That's the concern
of upstream.

In principle it's just a matter of fixing just a few things over the
coming versions.  But someone has to do it, otherwise the port will just
die.

Samuel

Re: patch8.diff updated Was: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Wed 21 May 2014 09:47:08 +0200, a écrit :
> > > +# Special treatment of EWOULDBLOCK for GNU/Hurd
> > > +# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
> > > +if egrep 'define EWOULDBLOCK EAGAIN' gen-sysinfo.go > /dev/null 2>&1; 
> > > then
> > > +  egrep '^const EWOULDBLOCK = Errno(_EWOULDBLOCK)' ${OUT} | \
> > > +sed -i.bak -e 's/_EWOULDBLOCK/_EAGAIN/' ${OUT}
> > 
> > I don't understand why you both pass the output of egrep to sed, and you
> > give the -i option to sed. AIUI, the
> > egrep '^const EWOULDBLOCK = Errno(_EWOULDBLOCK)'
> > part is completely unused, so you can just drop it.
> 
> Well, the -i option is to get a backup copy for debugging purposes, can
> safely be removed.

Err, no, -i completely changes the behavior of sed, which then doesn't
read its stdin at all any more, it will modify ${OUT} in-place instead.
It happens that it is what you want here.  But then just drop the egrep
just before, it really is useless now. And drop the .bak suffix, I don't
think the gnugo maintainers will want to see a .bak file lying behind.

> Good luck making the patch better. It worked for me, but as I wrote
> before I'm no sed/grep expert.

I'm not the one to be convinced, gnugo maintainers are the one to be.
I'm just telling you in advance what *they* will tell you.

Samuel

Re: patch8.diff updated Was: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Fri 16 May 2014 10:03:05 +0200, a écrit :
> is used in gcc-4.9-4.9.0/src/libgo/go/net/fd_unix.go:
> func dupCloseOnExec(fd int) (newfd int, err error) {
> if atomic.LoadInt32(&tryDupCloexec) == 1 && syscall.F_DUPFD_CLOEXEC!=0 {
> r0, _, e1 := syscall.Syscall(syscall.SYS_FCNTL, uintptr(fd),
> syscall.F_DUPFD_CLOEXEC, 0)

That code can not work as it is, fcntl is not a system call on
GNU/Hurd. Why isn't gccgo just using the C fcntl function?  That one
will just work and be portable.

> +# Special treatment of EWOULDBLOCK for GNU/Hurd
> +# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
> +if egrep 'define EWOULDBLOCK EAGAIN' gen-sysinfo.go > /dev/null 2>&1; then
> +  egrep '^const EWOULDBLOCK = Errno(_EWOULDBLOCK)' ${OUT} | \
> +sed -i.bak -e 's/_EWOULDBLOCK/_EAGAIN/' ${OUT}

I don't understand why you both pass the output of egrep to sed, and you
give the -i option to sed. AIUI, the
egrep '^const EWOULDBLOCK = Errno(_EWOULDBLOCK)'
part is completely unused, so you can just drop it.

> @@ -528,6 +540,12 @@
> +# Special treatment of st_dev for GNU/Hurd
> +# /usr/include/i386-gnu/bits/stat.h: #define st_dev st_fsid
> +if grep 'define st_dev st_fsid' gen-sysinfo.go > /dev/null 2>&1; then
> +  egrep '^type _stat ' gen-sysinfo.go > /dev/null 2>&1| \
> +  sed -i.bak -e 's/; st_fsid/; st_dev/' gen-sysinfo.go
> +fi

The same remark about egrep | sed -i applies here.

And anyway, why not simply using the very first patch you proposed,
which was:

@@ -536,6 +548,7 @@
 fi | sed -e 's/type _stat64/type Stat_t/' \
  -e 's/type _stat/type Stat_t/' \  
  -e 's/st_dev/Dev/' \
+ -e 's/st_fsid/Dev/' \
  -e 's/st_ino/Ino/g' \
  -e 's/st_nlink/Nlink/' \
  -e 's/st_mode/Mode/' \

which I said several times that it should be completely fine.

Samuel

Re: Hurd port for gcc go PATCH 7-9 (9)

[Samuel Thibault]

Svante Signell, le Tue 06 May 2014 14:13:54 +0200, a écrit :
> > > +# Special treatment of EWOULDBLOCK for GNU/Hurd
> > > +# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
> > > +egrep '^const EWOULDBLOCK = Errno(_EWOULDBLOCK)' ${OUT} | \
> > > +sed -i.bak -e 's/_EWOULDBLOCK/_EAGAIN/' ${OUT}
> > > +
> 
> This applies to all systems yes, how to modify?

Well, either explicitly test for the system, or find a way to make it
actually do things only for the systems which need it. You could for
instance grep for "#define EWOULDBLOCK EAGAIN".

> > and that:
> > 
> > > +# Special treatment of SYS_FCNTL for GNU/Hurd
> > > +if ! grep '^const SYS_FCNTL' ${OUT} >/dev/null 2>&1; then
> > > +  echo "const SYS_FCNTL = 0" >> ${OUT}
> > > +fi
> 
> And this applies to systems not defining FCNTL.
> How many systems could possibly be affected?

I misread it indeed, I'm sorry about that.  So it adds SYS_FCNTL = 0 to
any system which does not have it already.  What is the consequence of
this?  Where is this used?  (I can't find any go reference to SYS_FCNTL
in the gcc source)

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Tue 06 May 2014 15:25:38 +0200, a écrit :
> On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
> > Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> > > On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > > > Just to explicitly ask for it:
> > > > 
> > > > Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > > > > For some (yet) unknown reason all libgo tests fails with a segfault 
> > > > > when
> > > > > run in the build tree: make, sh or something else, the test commands 
> > > > > are
> > > > > rather hard to track.
> > > > 
> > > > Doesn't that dump a core?  Do you have /servers/crash properly pointing
> > > > to /servers/crash-dump-core and ulimit -u set to unlimited?
> > > 
> > > fsysopts /servers/crash
> > > ext2fs --writable --no-inherit-dir-group --store-type=typed device:hd0s1
> > 
> > See the type of file, it's a symlink, so just ls -l it.
> 
> ls -l /servers/crash
> lrw-r--r-- 1 root root 10 May 17  2013 /servers/crash -> crash-kill
> 
> Should I just ln -sf to change?

Yes.

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > Just to explicitly ask for it:
> > 
> > Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > > For some (yet) unknown reason all libgo tests fails with a segfault when
> > > run in the build tree: make, sh or something else, the test commands are
> > > rather hard to track.
> > 
> > Doesn't that dump a core?  Do you have /servers/crash properly pointing
> > to /servers/crash-dump-core and ulimit -u set to unlimited?
> 
> fsysopts /servers/crash
> ext2fs --writable --no-inherit-dir-group --store-type=typed device:hd0s1

See the type of file, it's a symlink, so just ls -l it.

> > > Number of tests succeeding with libpthread's stack guard fixed: 33 (and
> > > the other libc fixes)
> 
> Additionally 33 test pass with the fixed libpthread (some of them pass
> but segfault before finishing).

Ok, that parenthesis brings the sense to it :)

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Just to explicitly ask for it:

Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> For some (yet) unknown reason all libgo tests fails with a segfault when
> run in the build tree: make, sh or something else, the test commands are
> rather hard to track.

Doesn't that dump a core?  Do you have /servers/crash properly pointing
to /servers/crash-dump-core and ulimit -u set to unlimited?

> However, running the tests manually, sigh!, after installing gccgo and
> libgo5 from gcc-4.9-4.9.0-1 with split stack support the result is as
> follows:
> 
> Total: 122
> PASS: 95
> FAIL: 27

Good! :)

> Number of tests succeeding with libpthread's stack guard fixed: 33 (and
> the other libc fixes)

I'm not sure to understand: does it mean only 33 pass instead of 95?

> Note: In many of the failing tests, only a small subset of each test
> fails.

Ok, that's a good sign.

Samuel

Re: Hurd port for gcc go PATCH 7-9 (9)

[Samuel Thibault]

Svante Signell, le Tue 06 May 2014 10:58:38 +0200, a écrit :
> The patch for st_dev by Thomas Schwinge was not liked by Samuel

Uh?

I said “These should be fine, however.” and “a sed rule can't hurt even
if there is no occurrence...”

So just keep that precise part back as it was, no need for being clumsy.

What I however said was:

“Err, these seem to get applied to all systems, not just GNU/Hurd, isn't
that a concern?”

By that, I mean this:

> +# Special treatment of EWOULDBLOCK for GNU/Hurd
> +# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
> +egrep '^const EWOULDBLOCK = Errno(_EWOULDBLOCK)' ${OUT} | \
> +sed -i.bak -e 's/_EWOULDBLOCK/_EAGAIN/' ${OUT}
> +

and that:

> +# Special treatment of SYS_FCNTL for GNU/Hurd
> +if ! grep '^const SYS_FCNTL' ${OUT} >/dev/null 2>&1; then
> +  echo "const SYS_FCNTL = 0" >> ${OUT}
> +fi

AIUI, the patch you propose does those changes for all systems, not just
GNU/Hurd.  That most probably will pose a problem.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
> On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > > So we just need to fix guardsize in our libpthread.
> > 
> > (And I'll have a look at it).
> 
> Maybe this can fix the around 40 segfaults (of 50 failures) when split
> stack is disabled too? The segfaults are always around the same place in
> libpthread. 

Possibly, if libgo uses small stacks already.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.

It was not so difficult actually.

Svante, could you try this libpthread:

http://people.debian.org/~sthibault/tmp/libpthread.so.0.3

Thanks,
Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.

(And I'll have a look at it).

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space 
> available) 
> task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816

While inspecting this, I realized this is from __pthread_stack_alloc,
the only caller of vm_allocate with anywhere set to 0 which would have
such behavior. 8364 is really small for a stack (but that's expected
from -fsplit-stack), and the thing is: we have a bogus libpthread which
includes guardsize into stacksize.  I guess this is what happens: gcc
believes there is 8K, but our libpthread actually removes 4K from it for
guardsize, so the process will crash as soon as 4K are used on the
stack.

So we just need to fix guardsize in our libpthread.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Justus Winter, le Sat 26 Apr 2014 08:53:08 +0200, a écrit :
> task130(pid1182)->vm_map (0 49880 0 1133<--160(pid1182) 0 1 5 7 1) = 0 
> 2453504
> 
> We map that somewhere.
> 
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Deallocate the port.  Again, for some strange reason 133 == pn{ 25}.
> 
>   158<--157(pid1182)->io_map_request () = 0133<--162(pid1182)  (null)
> 
> Some more io_map.
> 
> task130(pid1182)->vm_map (2498560 8192 0 0133<--162(pid1182) 40960 1 3 7 
> 1) = 0x3 ((os/kern) no space available) 
> task130(pid1182)->vm_deallocate (2498560 8192) = 0 
> 
> Hum?
> 
> task130(pid1182)->vm_map (2498560 8192 0 0133<--162(pid1182) 40960 1 3 7 
> 1) = 0 2498560
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Success!

See the logic in elf/dl-load.c's _dl_map_object_from_fd and
sysdeps/mach/hurd/mmap.c. _dl_map_object_from_fd first gets somewhere
to map the SO (first __mmap call), and then, if bss is big, it maps
anonymous pages for it with MAP_FIXED, replacing the bss part of the SO:

2453504 + 49880 = 0x2632d8
2498560 + 8192 = 0x264000

So this seems like just normal behavior.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Fri 02 May 2014 10:03:23 +0200, a écrit :
> On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> > Hello,
> > 
> > Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > > most of them with a segfault.
> > > - Enabling split stack and using the libc Samuel built all 122 libgo
> > > tests fail with a segfault.
> > 
> > Please provide segfault backtrace, rpctrace, etc.  Otherwise we won't be
> > able to help you.
> 
> You already have one in this thread, analysed by Justus:
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01736.html

Yes, but that stack was without split stack fixed. The backtrace you
have just attached seems different.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> Thread 4 (Thread 1205.4):
> #0  0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
> err = 
> err = 
> user_option = 3
> user_timeout = 48
> m = 0x532370
> msgh_bits = 0
> remote_port = 268509186
> msgid = 21118
> save_data = 
> __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"

Ok, reading this again, this looks like what Justus analyzed.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Hello,

Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> - Without split stack enabled around 70 libgo tests pass and 50 fails,
> most of them with a segfault.
> - Enabling split stack and using the libc Samuel built all 122 libgo
> tests fail with a segfault.

Please provide segfault backtrace, rpctrace, etc.  Otherwise we won't be
able to help you.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > and similar configury is correct for the Hurd,
> 
> I have added the corresponding field, so we can just use the same offset
> as on Linux.

I have uploaded packages on http://people.debian.org/~sthibault/tmp/ so
Svante can try setting TARGET_THREAD_SPLIT_STACK_OFFSET to 0x30 with
them.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> and similar configury is correct for the Hurd,

I have added the corresponding field, so we can just use the same offset
as on Linux.

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Samuel Thibault, le Sat 12 Apr 2014 01:04:49 +0200, a écrit :
> Samuel Thibault, le Fri 11 Apr 2014 23:51:44 +0200, a écrit :
> > So, do we really want to let munmap poke a hole at address 0 and thus
> > let further vm_map() return address 0?
> 
> i.e. we could apply this:

I have applied it.

Samuel

Re: Hurd port for gcc go PATCH 7-9 (9)

[Samuel Thibault]

Svante Signell, le Mon 14 Apr 2014 09:59:03 +0200, a écrit :
> > > @@ -528,6 +538,8 @@
> > >  
> > >  # The stat type.
> > >  # Prefer largefile variant if available.
> > > +# Special treatment of st_dev for GNU/Hurd
> > > +# /usr/include/i386-gnu/bits/stat.h: #define st_dev st_fsid
> > >  stat=`grep '^type _stat64 ' gen-sysinfo.go || true`
> > >  if test "$stat" != ""; then
> > >grep '^type _stat64 ' gen-sysinfo.go
> > > @@ -536,6 +548,7 @@
> > >  fi | sed -e 's/type _stat64/type Stat_t/' \
> > >   -e 's/type _stat/type Stat_t/' \
> > >   -e 's/st_dev/Dev/' \
> > > + -e 's/st_fsid/Dev/' \
> > >   -e 's/st_ino/Ino/g' \
> > >   -e 's/st_nlink/Nlink/' \
> > >   -e 's/st_mode/Mode/' \
> 
> Don't know if any other system defines st_fsid as st_dev like Hurd does.
> If not this one would be fine too?

I don't know any other system doing it, but a sed rule can't hurt even
if there is no occurrence...

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Samuel Thibault, le Fri 11 Apr 2014 23:51:44 +0200, a écrit :
> So, do we really want to let munmap poke a hole at address 0 and thus
> let further vm_map() return address 0?

i.e. we could apply this:

diff --git a/sysdeps/mach/munmap.c b/sysdeps/mach/munmap.c
index 57d99f9..a46e3f1 100644
--- a/sysdeps/mach/munmap.c
+++ b/sysdeps/mach/munmap.c
@@ -27,6 +27,11 @@ int
 __munmap (__ptr_t addr, size_t len)
 {
   kern_return_t err;
+  if (addr == 0)
+{
+  errno = EINVAL;
+  return -1;
+}
   if (err = __vm_deallocate (__mach_task_self (),
 (vm_address_t) addr, (vm_size_t) len))
 {

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> and similar configury is correct for the Hurd,

It's not.  I've checked what TARGET_THREAD_SPLIT_STACK_OFFSET is, it's
an offset inside the tcbhead_t structure, and we don't have that field
at all...  We may want to extend our tcbhead_t the same way as Linux
i386.

> and figure out what's
> going on with the zero-page unmapping (discussed earlier in this thread),
> and then mmap failing with 1073741846 (EINVAL).

Here is the backtrace

#0  __vm_map (target_task=1, address=address@entry=0x1029cc4, 
size=size@entry=0, mask=mask@entry=0, anywhere=1, 
memory_object=memory_object@entry=0, offset=offset@entry=0, 
copy=copy@entry=1, cur_protection=cur_protection@entry=1, 
max_protection=max_protection@entry=7, inheritance=inheritance@entry=1)
at /usr/src/eglibc-2.18/build-tree/hurd-i386-libc/mach/vm_map.c:56
#1  0x0118a3e8 in __mmap (addr=0x0, len=0, prot=4, flags=2, fd=-1, offset=0) at 
../sysdeps/mach/hurd/mmap.c:145
#2  0x0804960d in __morestack_load_mmap ()
#3  0x08049d12 in __libc_csu_init ()
#4  0x010b4671 in __libc_start_main (main=0x80489dd , argc=1, 
argv=0x1029de4, init=0x8049cc0 <__libc_csu_init>, fini=0x8049d30 
<__libc_csu_fini>, rtld_fini=0xfb90 <_dl_fini>, 
stack_end=0x1029ddc) at libc-start.c:246
#5  0x08048901 in _start ()

It's indeed:

/* This function is called at program startup time to make sure that
   mmap, munmap, and getpagesize are resolved if linking dynamically.
   We want to resolve them while we have enough stack for them, rather
   than calling into the dynamic linker while low on stack space.  */

void
__morestack_load_mmap (void)
{
  /* Call with bogus values to run faster.  We don't care if the call
 fails.  Pass __MORESTACK_CURRENT_SEGMENT to make sure that any
 TLS accessor function is resolved.  */
  mmap (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
  mprotect (NULL, 0, 0);
  munmap (0, getpagesize ());
}

Yes...

So, do we really want to let munmap poke a hole at address 0 and thus
let further vm_map() return address 0?

Samuel

Re: Hurd port for gcc go PATCH 0-3 (9)

[Samuel Thibault]

Svante Signell, le Fri 11 Apr 2014 14:47:21 +0200, a écrit :
>  #ifdef TARGET_LIBC_PROVIDES_SSP
> +/* i386 glibc provides __stack_chk_guard in %gs:0x14.  */
> +#define TARGET_THREAD_SSP_OFFSET 0x14

Err, not the Hurd variant, no.  Is it really needed?

> @@ -682,7 +686,7 @@
>  go_net_cgo_file = go/net/cgo_linux.go
>  go_net_sock_file = go/net/sock_linux.go
>  go_net_sockopt_file = go/net/sockopt_linux.go
> -go_net_sockoptip_file = go/net/sockoptip_linux.go go/net/sockoptip_posix.go
> +go_net_sockoptip_file = go/net/sockoptip_linux.go go/net/sockoptip_bsd.go
>  else

This seems doubtful, isn't that the Linux case?

Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Samuel Thibault]

Hello,

Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor  wrote:
> > Go can work without split stack.  In that case libgo will use much
> > larger stacks for goroutines, to reduce the chance of running out of
> > stack space (see StackMin in libgo/runtime/proc.c).  So the number of
> > simultaneous goroutines that can be run will be limited.  This is
> > usually OK on x86_64 but it does hamper Go programs running on 32-bit
> > x86.
> 
> OK, but that's not the most pressing issue we're having right now.
> Anyway, as it stands, the split-stack code doesn't work on Hurd, so I
> disabled it in r200434 as follows:

Maybe you'd want to re-enable it, now that we have got rid of threadvars :)

Samuel

Re: GCC for GNU Hurd: MACH built-in preprocessor macro (was: gdb: FTBFS on hurd-i386 (for review))

[Samuel Thibault]

Thomas Schwinge, le Mon 05 Nov 2012 07:09:43 +0100, a écrit :
> Samuel, is there any way you can unpack all Debian source packages on a
> Debian machine, and run a recursive grep command (I can work out a
> suitable regex) to see where removing the MACH or __MACH built-in
> preprocessor macros might cause trouble?

Heh, it had to happen just now: http://codesearch.debian.net/ was
announced :)

Samuel

Re: GCC for GNU Hurd: MACH built-in preprocessor macro (was: gdb: FTBFS on hurd-i386 (for review))

[Samuel Thibault]

Thomas Schwinge, le Mon 05 Nov 2012 07:09:43 +0100, a écrit :
> Samuel, is there any way you can unpack all Debian source packages on a
> Debian machine, and run a recursive grep command (I can work out a
> suitable regex) to see where removing the MACH or __MACH built-in
> preprocessor macros might cause trouble?

Sure!

Samuel