Regeneration of 'gcc/config/riscv/riscv.opt.urls' (was: [PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64))

[Thomas Schwinge]

Hi!

On 2024-04-09T09:24:29-0700, Palmer Dabbelt  wrote:
> On Tue, 09 Apr 2024 01:04:34 PDT (-0700), buga...@gmail.com wrote:
>> On Tue, Apr 9, 2024 at 10:27 AM Thomas Schwinge  
>> wrote:
>>> Thanks, pushed to trunk branch:
>>>
>>>   - commit 532c57f8c3a15b109a46d3e2b14d60a5c40979d5 "Move GNU/Hurd 
>>> startfile spec from config/i386/gnu.h to config/gnu.h"
>>>   - commit 9670a2326333caa8482377c00beb65723b7b4b26 "aarch64: Add support 
>>> for aarch64-gnu (GNU/Hurd on AArch64)"
>>>   - commit 46c91665f4bceba19aed56f5bd6e934c548b84ff "libgcc: Add basic 
>>> support for aarch64-gnu (GNU/Hurd on AArch64)"
>>
>> \o/ Thanks a lot!
>>
>> This will unblock merging the aarch64-gnu glibc port upstream.

\o/


>> I assume the buildbot failure that I just got an email about is
>> unrelated; it's failing on some RISC-V thing.
>
> Sorry if I missed something here, do you have a pointer?

<https://inbox.sourceware.org/20240409074850.ed7bd3858...@sourceware.org>
and several more such messages, requesting:

--- a/gcc/config/riscv/riscv.opt.urls
+++ b/gcc/config/riscv/riscv.opt.urls
@@ -89,3 +89,5 @@ UrlSuffix(gcc/RISC-V-Options.html#index-minline-strncmp)
 minline-strlen
 UrlSuffix(gcc/RISC-V-Options.html#index-minline-strlen)
 
+; skipping UrlSuffix for 'mtls-dialect=' due to finding no URLs
+

To be fixed by
<https://inbox.sourceware.org/20240409145724.9640-1-ishitatsuy...@gmail.com>
"Regenerate opt.urls".


Grüße
 Thomas

Re: [PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64)

[Thomas Schwinge]

Hi!

On 2024-04-05T15:13:33+0300, Sergey Bugaev  wrote:
> On Tue, Apr 2, 2024 at 8:26 PM Richard Sandiford
>  wrote:
>> I don't know if you're waiting on me, but just in case: this and patch 3
>> still LGTM if Thomas is OK with them.
>
> Thanks. Thomas asked me to resubmit with Changelog entries added (but
> hasn't pointed out anything else), so this is waiting for him to
> confirm that this looks OK now.

Thanks, pushed to trunk branch:

  - commit 532c57f8c3a15b109a46d3e2b14d60a5c40979d5 "Move GNU/Hurd startfile 
spec from config/i386/gnu.h to config/gnu.h"
  - commit 9670a2326333caa8482377c00beb65723b7b4b26 "aarch64: Add support for 
aarch64-gnu (GNU/Hurd on AArch64)"
  - commit 46c91665f4bceba19aed56f5bd6e934c548b84ff "libgcc: Add basic support 
for aarch64-gnu (GNU/Hurd on AArch64)"


Grüße
 Thomas

Re: [PATCH gcc 1/3] Move GNU/Hurd startfile spec from config/i386/gnu.h to config/gnu.h

[Thomas Schwinge]

Hi!

On 2024-01-03T09:49:06+, Richard Sandiford  
wrote:
> The series looks good to me FWIW, but Thomas should have the final say.

Richard, thanks for your review.

Sergey, great work on aarch64 GNU/Hurd!  (... where these GCC bits
clearly were the less complicated part...)  ;-)

Please re-submit with ChangeLog updates added to the Git commit logs; see
 ->
, and/or 'git log'
for guidance.  You may use
'contrib/gcc-changelog/git_check_commit.py --print-changelog' to verify.


Grüße
 Thomas

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

[Thomas Schwinge]

Hi!

Please note that emails to , or
 don't reach me anymore, and, at least for
the time being, likewise for  --
 is the new thing; see
.
(Or use , ,
, as before.)


On 2024-03-01T02:33:10+0100, Samuel Thibault  wrote:
> 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, pushed as commit b7c4ae5ace82b81dafffbc50e8026adfa3cc76e7.


Grüße
 Thomas

hurd: Ad default-pie and static-pie support

[Thomas Schwinge]

Hi!

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.


Grüße
 Thomas


-
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 .
 #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
-- 
2.34.1

hurd: Add multilib paths for gnu-x86_64

[Thomas Schwinge]

Hi!

On 2023-10-28T21:19:59+0200, Samuel Thibault  wrote:
> We need the multilib paths in gcc to find e.g. glibc crt files on
> Debian.

ACK.

> This is essentially based on t-linux64 version.

Yes, but isn't the overall setup diverged from GNU/Linux?

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'.  Instead, I
suppose, we should handle 'i386/t-linux64' and 'i386/t-gnu64' alike, and
resolve relevant configuration differences.

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?

However, such things can certainly be resolved incrementally, later on.
I understand that your change does work for you as-is, so I've now pushed
that to master branch in commit 5707e9db9c398d311defc80c5b7822c9a07ead60
"hurd: Add multilib paths for gnu-x86_64", see attached.


Grüße
 Thomas


-
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 5707e9db9c398d311defc80c5b7822c9a07ead60 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sat, 6 May 2023 13:50:36 +0200
Subject: [PATCH] hurd: Add multilib paths for gnu-x86_64

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:

	* config/i386/t-gnu64: New file.
	* config.gcc [x86_64-*-gnu*]: Add i386/t-gnu64 to
	tmake_file.
---
 gcc/config.gcc  |  3 +++
 gcc/config/i386/t-gnu64 | 38 ++
 2 files changed, 41 insertions(+)
 create mode 100644 gcc/config/i386/t-gnu64

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3000379cafc..e62849c1230 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5973,6 +5973,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
new file mode 100644
index 000..23ee6823d65
--- /dev/null
+++ 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)
-- 
2.34.1

[GCC] In 'contrib/config-list.mk', clarify i686-symbolics-gnu to i686-gnu (was: RFA: Add makefile for cross-configuration torture test)

[Thomas Schwinge]

Hi!

On 2011-04-13T06:49:31-0400, Joern Rennecke  wrote:
> [...]
> This Makefile is supposed to give coverage of all the main configure targets
> and notable variants that enable different config files.
> [...]

> --- contrib/config-list.mk(revision 0)
> +++ contrib/config-list.mk(revision 0)

> +LIST = [...]
> +  [...]
> +  i686-elf i686-kopensolaris-gnu i686-symbolics-gnu i686-pc-msdosdjgpp \
> +  [...]

Unless anybody has any rationale to share about i686-symbolics-gnu,
I intend to soon push the attached
"In 'contrib/config-list.mk', clarify i686-symbolics-gnu to i686-gnu".


Grüße
 Thomas


-
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 18712980c1007d40c30d1893d47475c928e19e95 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 10 Feb 2023 10:43:24 +0100
Subject: [PATCH] In 'contrib/config-list.mk', clarify i686-symbolics-gnu to
 i686-gnu

Already in the first revision of 'contrib/config-list.mk', i686-symbolics-gnu
has been present, but it's not clear to me whether that was meant to be
Symbolics as in the manufacturer, <https://en.wikipedia.org/wiki/Symbolics>,
with GNU (that is, GNU/Hurd) kernel/operating system (user land), or Symbolics
kernel with GNU operating system (user land)?

I can't find any mention of "Symbolics" in the history of 'config.sub'
upstream.

Either way, GCC configures i686-symbolics-gnu exactly the same as i686-gnu:

$ sed -n -e '/Using .* host machine hooks\.$/q' -e '/^Using the following target machine macro files:$/,$p' log/i686-gnu-make.out
Using the following target machine macro files:
[...]/gcc/config/vxworks-dummy.h
[...]/gcc/config/i386/i386.h
[...]/gcc/config/i386/unix.h
[...]/gcc/config/i386/att.h
[...]/gcc/config/elfos.h
[...]/gcc/config/gnu-user.h
[...]/gcc/config/glibc-stdint.h
[...]/gcc/config/i386/gnu-user-common.h
[...]/gcc/config/i386/gnu-user.h
[...]/gcc/config/gnu.h
[...]/gcc/config/i386/gnu.h
[...]/gcc/config/initfini-array.h

..., so let's clarify i686-symbolics-gnu to i686-gnu.

	contrib/
	* config-list.mk (LIST): Clarify i686-symbolics-gnu to i686-gnu.
---
 contrib/config-list.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 20b8f4a196f..4c0a94d5c37 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -50,7 +50,7 @@ LIST = aarch64-elf aarch64-freebsd13 aarch64-linux-gnu aarch64-rtems \
   i686-pc-linux-gnu i686-apple-darwin i686-apple-darwin9 i686-apple-darwin10 \
   i686-freebsd13 i686-kfreebsd-gnu \
   i686-netbsdelf9 \
-  i686-openbsd i686-elf i686-kopensolaris-gnu i686-symbolics-gnu \
+  i686-openbsd i686-elf i686-kopensolaris-gnu i686-gnu \
   i686-pc-msdosdjgpp i686-lynxos i686-nto-qnx \
   i686-rtems i686-solaris2.11 i686-wrs-vxworks \
   i686-wrs-vxworksae \
-- 
2.25.1

Re: [PATCH] Add x86_64-gnu target to contrib/config-list.mk

[Thomas Schwinge]

Hi!

On 2023-02-02T00:55:01-0500, Flavio Cruz  wrote:
> contrib/ChangeLog:
>   * config-list.mk: Add x86_64-gnu to list of archs.
>
> Signed-off-by: Flavio Cruz 

Thanks, pushed to GCC master branch in
commit e635681dd26abf8243b49f6fd39d3582d57225ba
"Add x86_64-gnu target to contrib/config-list.mk".


Grüße
 Thomas


>  contrib/config-list.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index 20b8f4a196f..661b11c9bbd 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -96,7 +96,7 @@ LIST = aarch64-elf aarch64-freebsd13 aarch64-linux-gnu 
> aarch64-rtems \
>sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux \
>sparc64-netbsd sparc64-openbsd \
>v850e1-elf v850e-elf v850-elf v850-rtems vax-linux-gnu \
> -  vax-netbsdelf visium-elf x86_64-apple-darwin \
> +  vax-netbsdelf visium-elf x86_64-apple-darwin x86_64-gnu \
>x86_64-pc-linux-gnuOPT-with-fpmath=avx \
>x86_64-elfOPT-with-fpmath=sse x86_64-freebsd13 x86_64-netbsd \
>x86_64-w64-mingw32 \
-
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

Re: [PATCH] Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd

[Thomas Schwinge]

Hi!

On 2023-01-27T21:15:01-0500, Flávio Cruz  wrote:
> Not sure what happened, but here's the patch as an attachment. Thanks for
> your patience.

Thanks, that worked.  Without any changes now pushed to master branch in
commit 5f8950b403f6351f125d8281d2e7430a43e7d125
"Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd",
see attached.

I'll watch how x86_64 GNU/Hurd develops!  :-)


Grüße
 Thomas


> On Fri, Jan 27, 2023 at 4:16 PM Thomas Schwinge 
> wrote:
>
>> Hi Flavio!
>>
>> Sorry to bother you one last time (hopefully):
>>
>> On 2023-01-27T01:49:25-0500, Flavio Cruz  wrote:
>> > On Thu, Jan 26, 2023 at 09:34:16AM +0100, Thomas Schwinge wrote:
>> >>As you don't have FSF Copyright Assignment on file for GCC (as far as I
>> >>can tell), are you either going to get that, or re-submit this patch with
>> >>DCO ('Signed-off-by:' tag), <https://gcc.gnu.org/contribute.html#legal>?
>> >
>> > Yes, I think I have it for Hurd related projects
>>
>> Yes.
>>
>> > but not GCC. Added Signed-off-by.
>>
>> ACK, thanks.
>>
>> > Revisted patch is inlined below. Also added the ChangeLog details.
>>
>> Thanks!
>>
>> If I 'git am' that one, I get:
>>
>> warning: Patch sent with format=flowed; space at the end of lines might 
>> be lost.
>> Applying: Add support for x86_64-*-gnu-* targets to build x86_64 
>> gnumach/hurd
>> error: corrupt patch at line 180
>> Patch failed at 0001 Add support for x86_64-*-gnu-* targets to build 
>> x86_64 gnumach/hurd
>> [...]
>>
>> That's due to:
>>
>> Content-Type: text/plain; charset="iso-8859-1"; format=flowed
>>
>> Is it easy for you to re-send that "differently"?  (Or, just attach the
>> file generated by 'git format-patch'.)  If that's inconvenient, then I'll
>> fix it up manually, no worries.
>>
>>
>> Grüße
>>  Thomas


-
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 5f8950b403f6351f125d8281d2e7430a43e7d125 Mon Sep 17 00:00:00 2001
From: Flavio Cruz 
Date: Thu, 26 Jan 2023 22:45:27 -0500
Subject: [PATCH] Add support for x86_64-*-gnu-* targets to build x86_64
 gnumach/hurd

Tested by building a toolchain and compiling gnumach for x86_64 [1].
This is the basic version without unwind support which I think is only
required to implement exceptions.

[1]
https://github.com/flavioc/cross-hurd/blob/master/bootstrap-kernel.sh.

gcc/ChangeLog:
	* config.gcc: Recognize x86_64-*-gnu* targets and include
	i386/gnu64.h.
	* config/i386/gnu64.h: Define configuration for new target
	including ld.so location.

libgcc/ChangeLog:
	* config.host: Recognize x86_64-*-gnu* targets.
	* config/i386/gnu-unwind.h: Update to handle __x86_64__ with a
	TODO for now.

Signed-off-by: Flavio Cruz 
---
 gcc/config.gcc  |  5 -
 gcc/config/i386/gnu64.h | 40 +
 libgcc/config.host  |  8 ++-
 libgcc/config/i386/gnu-unwind.h | 10 +
 4 files changed, 61 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/i386/gnu64.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 744b46fb3b0..f0958e1c959 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1971,7 +1971,7 @@ i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-gnu* | i[34567]8
 		;;
 	esac
 	;;
-x86_64-*-linux* | x86_64-*-kfreebsd*-gnu)
+x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | x86_64-*-gnu*)
 	tm_file="${tm_file} i386/unix.h i386/att.h elfos.h gnu-user.h glibc-stdint.h \
 		 i386/x86-64.h i386/gnu-user-common.h i386/gnu-user64.h"
 	case ${target} in
@@ -1982,6 +1982,9 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu)
 	x86_64-*-kfreebsd*-gnu)
 		tm_file="${tm_file} kfreebsd-gnu.h i386/kfreebsd-gnu64.h"
 		;;
+	x86_64-*-gnu*)
+		tm_file="${tm_file} gnu.h i386/gnu64.h"
+		;;
 	esac
 	tmake_file="${tmake_file} i386/t-linux64"
 	x86_multilibs="${with_multilib_list}"
diff --git a/gcc/config/i386/gnu64.h b/gcc/config/i386/gnu64.h
new file mode 100644
index 000..a411f0e802a
--- /dev/null
+++ b/gcc/config/i386/gnu64.h
@@ -0,0 +1,40 @@
+/* Configuration for an x86_64 running GNU with ELF as the target machine.  */
+
+/*
+Copyright (C) 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 of the License, or
+(at your op

Re: [PATCH] Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd

[Thomas Schwinge]

Hi Flavio!

On 2022-12-26T12:34:28-0500, Flavio Cruz via Gcc-patches 
 wrote:
> Tested by building a toolchain and compiling gnumach for x86_64

Oh, wow, so this is indeed happening, finally!  :-D

> This is the basic version without unwind support which I think is only 
> required to
> implement exceptions.

ACK, this can all be tuned later.  We understand that ABI to be
completely unstable at this point.


Your patch generally looks good, and I'll drop it into my regular
x86_64-pc-linux-gnu testing, to verify that we don't accidentally break
things re 'x86_64-*-gnu*' matching (but I think we're safe).


As you don't have FSF Copyright Assignment on file for GCC (as far as I
can tell), are you either going to get that, or re-submit this patch with
DCO ('Signed-off-by:' tag), ?


While at that, please also adjust:

> --- /dev/null
> +++ b/gcc/config/i386/gnu64.h
> @@ -0,0 +1,40 @@
> +/* Configuration for an x86_64 running GNU with ELF as the target machine.  
> */
> +
> +/*
> +Copyright (C) 2022 Free Software Foundation, Inc.

^ 2023 ;-)


Grüße
 Thomas
-
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

Hurd wiki/web pages (was: Ikiwiki maintenance)

[Thomas Schwinge]

Hi!

For context: see

"Staging Area" regarding the relationship between
 and
.

On 2021-11-09T15:32:18+0100, Richard Braun  wrote:
> The ikiwiki package on darnassus has version 3.20140227, and it's
> starting to become a small problem with maintenance.

The Hurd wiki/web pages use a few ikiwiki plugins (kept inside the Hurd
web sources tree) that require "attention" (occasional
adaptation/porting) when updating ikiwiki.  Back then, I used to do that
every year or so -- but evidently have not for a long time, and I'm not
able to allocate proper time.

> How do we deal
> with that ?

I don't immediately have a good suggestion, I'm afraid.


Let's first work on answering the higher-level question, what we
generally want to do with (a) the wiki, and (b) the synchronization to
the GNU web server.  (Richard asked about darnassus/ikiwiki specifically,
but (b) is directly related to that, as the same ikiwiki rendering is
used for that.)

Is (a) still useful?  I found it useful, when I (really a lot!) and also
others did invest considerable time in maintaining the content.  After my
departure, Samuel as well as a few other contributors, one-off or more,
did continue to maintain the content -- so I do assume it still provides
more value than "baggage"?  From that it would follow that we should keep
the wiki alive, and thus need to resolve the ikiwiki issues in some way.
(Or, someone needs to invest proper time to convert the whole thing into
a more maintainable form, like I had done in 2007,
.)

Regarding (b), this too is non-trivial now, because all the changes of
the past years (since last time I did this, 2018-05-25) need to be
reviewed/"sanitized" to comply with GNU standards in order to be
published on the GNU web server.  (It seems that Samuel has manually
updated a few pages on the GNU web server, so these changes there also
need to be consolidated with an actual wiki rendering.  No criticism; I
very well understand that's the best he could easily do.)

As we're seeing, without dedicated maintenance (that I can't provide
anymore), it's problematic to keep a "wild" wiki and GNU-policied web
pages in sync.  Should we loosen the bonds: continue with the wiki, and
replace  with a new simple stub page?


Richard, sorry for not simply answering your actual question, but I hope
we'll get there.


Grüße
 Thomas

Re: [PATCH] Hurd: Enable ifunc by default

[Thomas Schwinge]

Hi!

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.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From e9cb89b936f831a02318d45fc4ddb06f7be55ae4 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sun, 8 Nov 2020 23:52:51 +0100
Subject: [PATCH] Hurd: Enable ifunc by default

The binutils bugs seem to have been fixed.

	gcc/
	* config.gcc [$target == *-*-gnu*]: Enable
	'default_gnu_indirect_function'.
---
 gcc/config.gcc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 4bec543fa76..9fb57e96121 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3598,7 +3598,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.17.1

>From 92b131491c22eb4e4b663d226e9d97f1fd693063 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sun, 8 Nov 2020 23:52:51 +0100
Subject: [PATCH] Hurd: Enable ifunc by default

The binutils bugs seem to have been fixed.

	gcc/
	* config.gcc [$target == *-*-gnu*]: Enable
	'default_gnu_indirect_function'.

(cherry picked from commit e9cb89b936f831a02318d45fc4ddb06f7be55ae4)
---
 gcc/config.gcc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 67bce508a1d..cb3e3238e91 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3542,7 +3542,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.17.1

>From 0313ce139f4ca3c96db9dc82125ec9e4a167a224 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sun, 8 Nov 2020 23:52:51 +0100
Subject: [PATCH] Hurd: Enable ifunc by default

The binutils bugs seem to have been fixed.

	gcc/
	* config.gcc [$target == *-*-gnu*]: Enable
	'default_gnu_indirect_function'.

(cherry picked from commit e9cb89b936f831a02318d45fc4ddb06f7be55ae4)
---
 gcc/config.gcc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 477aba7e0f6..82f80d4c748 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3283,7 +3283,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.17.1

>From 975b0fa0f43e84bed3cb1b2b593132bc219f962c Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sun, 8 Nov 2020 23:52:51 +0100
Subject: [PATCH] Hurd: Enable ifunc by default

The binutils bugs seem to have been fixed.

	gcc/
	* config.gcc [$target == *-*-gnu*]: Enable
	'default_gnu_indirect_function'.

(cherry picked from commit e9cb89b936f831a02318d45fc4ddb06f7be55ae4)
---
 gcc/config.gcc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 61bf317ea11..af9d1221da8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3174,7 +3174,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.17.1

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

[Thomas Schwinge]

Hi!

On 2020-12-21T15:36:30+0100, Samuel Thibault  wrote:
> When the application sets SA_SIGINFO, the signal trampoline parameters
> are different to follow POSIX.

Thanks (and sorry for the delay), pushed "hurd: libgcc unwinding over
signal trampolines with SIGINFO" to master branch in commit
2b356e689c334ca4765a9ffd95a76cf715447200, and cherry-picked into
releases/gcc-10 branch in commit
2c4d3e6db8583c83f4252bb0c78b85f174420a90, releases/gcc-9 branch in commit
23b1bb7b22aa23a1f096448c319856cbeb720082, releases/gcc-8 branch in commit
c6c6d1d33533a3107bec0bf6f149761b4084d8b4, see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 2b356e689c334ca4765a9ffd95a76cf715447200 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Mon, 21 Dec 2020 15:36:30 +0100
Subject: [PATCH] hurd: libgcc unwinding over signal trampolines with SIGINFO

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.
---
 libgcc/config/i386/gnu-unwind.h | 60 ++---
 1 file changed, 47 insertions(+), 13 deletions(-)

diff --git a/libgcc/config/i386/gnu-unwind.h b/libgcc/config/i386/gnu-unwind.h
index d69d07c1c80..0632348d4cd 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)>sc_eax - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)>sc_ecx - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)>sc_edx - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)>sc_ebx - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)>sc_ebp - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)>sc_esi - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)>sc_edi - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)>sc_eip - usp;
+}
+  else
+{
+  /* This is not a valid sigcode, assume SIGINFO.  */
+  ucontext_t *uctxp = handler_args->posix.uctxp;
+  gregset_t *gregset = >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)>sc_eax - usp;
   fs->regs.reg[1].how = REG_SAVED_OFFSET;
-  fs->regs.reg[1].loc.offset = (unsigned long)>sc_ecx - usp;
   fs->regs.reg[2].how = REG_SAVED_OFFSET;
-  fs->regs.reg[2].loc.offset = (unsigned long)>sc_edx - usp;
   fs->regs.reg[3].how = REG_SAVED_OFFSET;
-  fs->regs.reg[3].loc.offset = (unsigned long)>sc_ebx - usp;
   fs->regs.reg[5].how = REG_SAVED_OFFSET;
-  fs->regs.reg[5].loc.offset = (unsigned long)>sc_ebp - usp;
   fs->regs.reg[6].how = REG_SAVED_OFFSET;
-  fs->regs.reg[6].loc.offset = (unsigned long)>sc_esi - usp;
   fs->regs.reg[7].how = REG_SAVED_OFFSET;
-  fs->regs.reg[7].loc.offset = (unsigned long)>sc_edi - usp;
   fs->regs.reg[8].how = REG_SAVED_OFFSET;
-  fs->regs.reg[8].loc.offset = (unsigned long)>sc_eip - usp;
+
   fs->retaddr_column = 8;
   fs->signal_frame = 1;
 
-- 
2.17.1

>From 

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

[Thomas Schwinge]

Hi!

On 2020-06-08T13:49:55+0200, Samuel Thibault  wrote:
> 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.

Well, it was easy enough to just put it onto all active branches, so I've
now pushed "hurd: libgcc unwinding support over signal trampolines" to
master branch in commit 5e2eebc80d6eeca24745c27a925afdb64292ed22,
releases/gcc-10 branch in commit
a2b187c13919987ca0444ab7c701f9f93ee536c2, releases/gcc-9 branch in commit
cd32b2c51b913eed517e9503009fb3f0822d9cab, releases/gcc-8 branch in commit
9c5787ea072e16f26c9950139c00ae28fddadd72, see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 5e2eebc80d6eeca24745c27a925afdb64292ed22 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Fri, 29 May 2020 13:46:50 +0200
Subject: [PATCH] hurd: libgcc unwinding support over signal trampolines

	libgcc/
	* config.host (md_unwind_header) : Set to
	'i386/gnu-unwind.h'
	* config/i386/gnu-unwind.h: New file.

Signed-off-by: Thomas Schwinge 
---
 libgcc/config.host  |   8 ++-
 libgcc/config/i386/gnu-unwind.h | 107 
 2 files changed, 114 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/i386/gnu-unwind.h

diff --git a/libgcc/config.host b/libgcc/config.host
index 2cd420971675..044b34d53ccd 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/libgcc/config/i386/gnu-unwind.h b/libgcc/config/i386/gnu-unwind.h
new file mode 100644
index ..db47f0ac1d4b
--- /dev/null
+++ b/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 00 	lcall  $7,$0
+ *  12:	89 01	movl   %eax, (%ecx)
+ *  14:	89 dc	movl   %ebx, %esp  switch to signal st

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

[Thomas Schwinge]

Hi Samuel!

On 2020-05-29T13:46:50+0200, Samuel Thibault  wrote:
> libgcc is currently missing the support for unwinding over signal
> trampolines on GNU/Hurd.

ACK.  Has been on my long TODO list for a long time.  ;-)

> The attached patch implements it.

Thanks!

I'm not intimately familiar with the unwinding implementation, but your
changes look quite what I'd have guessed they'd look like, and also
somewhat similar to 'libgcc/config/i386/linux-unwind.h'.  (I'll get
there, eventually, again..., but) I'm not currently set up to test this,
but I'll assume you have.

Which GCC branches would you like this on?

> --- /dev/null
> +++ b/src/libgcc/config/i386/gnu-unwind.h
> @@ -0,0 +1,107 @@

> + * 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;

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.


Grüße
 Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: Google Summer of Code

[Thomas Schwinge]

Hi!

On 2020-01-26T20:05:46+0100, Almudena Garcia  wrote:
> Does anyone knows if this year GNU apply to GSOC?
> The deadline is February 5.
>
> https://summerofcode.withgoogle.com/get-started/

Yes, and now waiting for Google to decide.  See
.


> I'm interested in apply to continue my Hurd SMP project

Thanks for your interest!  As Joshua wrote: "need to find a Hurd
developer to mentor you".


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: ssh and scp get stuck after some amount of data

[Thomas Schwinge]

Hi!

Ha, I remembered right that I had seen such a problem reported before...


On 2018-01-15T12:31:04+0100, Bruno Haible  wrote:
> I tried:
>> # tar cf - directory | ssh bruno@10.0.2.2 tar xf -
>> It hangs after transferring 1.6 GB. I.e. no more data arrives within 15 
>> minutes.

You were lucky: for me it stopped much earlier (a few dozen MiB) -- the
file I'm trying to transfer is just 460 MiB in size.  ;-)

> Found a workaround: Throttling of the bandwidth.
> - Throttling at the network adapter level [1] is not applicable to Hurd.
> - The 'throttle' program [2] is no longer available.
> - But a replacement program [3] is available.

Or use the '--bwlimit' functionality of 'rsync', or the '--rate-limit'
functionality of 'pv', which are often already packaged, readily
available.

> The command that worked for me (it limits the bandwidth to 1 MB/sec):
>
> # tar cf - directory | ~/throttle.py --bandwidth 1024576 | ssh bruno@10.0.2.2 
> tar xf -

I thus tried:

$ pv --rate-limit 1M [file] | ssh [...] 'cat > [file]'

..., which crashed after 368 MiB.  After rebooting, a 'rsync -Pa
--inplace --bwlimit=500K' was then able to complete the transfer; the two
files' checksums do match.


> But really, this is only a workaround. It smells like a bug in ssh or the 
> Hurd.

As all networking seems to go down, maybe it's that the GNU Hurd
networking stack ('pfinet', 'netdde') gets "overwhelmed" by that much
data.


(That was on a Debian GNU/Hurd installation that's more than a one year
out of date, so there's a -- slight? ;-D -- chance that this has been
fixed already.)


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: When does gnu.org/s/hurd update?

[Thomas Schwinge]

Hi!

On 2019-09-06T22:12:51+0200, Muto  wrote:
> As I understand it, gnu.org/s/hurd is the "official" website for the
> Hurd, but it isn't editable like the Darnassus site.

Correct.

> Is there a reason
> for this that I should know about?

Content published from gnu.org has to be held to a higher standard than
what sometimes is added to/changed on the wiki.  Basically, just like
code patches have to be reviewed before they get into the official
repositories.  Only that for this web content, the review/rework happens
after it is published on the wiki.  This should be explained on
.

> The news on gnu.org/s/hurd is still
> stuck on 2016. Is there someone responsible for updating the site on the
> GNU servers?

That's me, and it will happen one day.  I'm aware that I'm way behind
what would be a reasonable expectation for the time it takes for this
manual synchronization to happen.

> I looked around and even asked, but I couldn't find a concrete answer.

Again, this should be explained on
.


Grüße
 Thomas


signature.asc
Description: PGP signature

[Hauke Goos-Habermann] Hurd booth/talk/workshop on Kieler Open Source und Linux Tage?

[Thomas Schwinge]

Hi!

Anyone available?  (I'm not, but thanks for asking, Hauke.)

| From: Hauke Goos-Habermann 
| Subject: Hurd booth/talk/workshop on Kieler Open Source und Linux Tage?
| To: hurd-maintain...@gnu.org
| Message-ID: 
| Date: Mon, 8 Jul 2019 15:32:16 +0200
| 
| Hi,
| 
| we are organising our 17th "Kieler Open Source und Linux Tage" (northern of
| Germany, www.kielux.de), a conference with 3 parallel tracks with talks and
| workshops and a smal exhibition for open source community projects and 
companies.
| 
| Is there anybody who would like to hold a talk and/or give a workshop and/or
| make a booth on our event (20th - 21th September)?e
| 
| Cu Hauke


Grüße
 Thomas


signature.asc
Description: PGP signature

[committed] [PR89221] Continue to default to '--disable-frame-pointer' for x86 GNU systems (was: [PATCH v2, i386]: Fix PR89221, --enable-frame-pointer does not work as intended)

[Thomas Schwinge]

Hi!

On Sun, 10 Feb 2019 20:51:39 +0100, Uros Bizjak  wrote:
> On Fri, Feb 8, 2019 at 1:24 PM Uros Bizjak  wrote:
> > Attached patch fixes --enable-frame-pointer handling [...]

ACK.

> Please note that this fix will re-enable frame pointer for all targets
> but linux* or darwin[[8912]]. However, since builds for e.g. cygwin
> and mingw survived just well without frame pointers in the mean time,
> we should probably list these targets as targets without frame
> pointers by default.

I agree, this would cause the least surprise, to simply keep the previous
default of '--disable-frame-pointer'.  Until such a global change is
agreed on, and made...

> Maintainers should decide.

The GNU/Hurd maintainer has decided (and also made a decision for
GNU/k*BSD); committed the attached to trunk in r271028.


Grüße
 Thomas


From 679a49952fe543043047267cc8500c5cc1065b7b Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Thu, 9 May 2019 09:51:59 +
Subject: [PATCH] [PR89221] Continue to default to '--disable-frame-pointer'
 for x86 GNU systems

The recent trunk r270914 for PR89221 "--enable-frame-pointer does not work as
intended" fixed a scripting defect in the x86 '--enable-frame-pointer'
handling.

This has the side effect that, for example, for '--target=i686-gnu' this is now
enabled by default: 'USE_IX86_FRAME_POINTER=1' is added to 'tm_defines'.  Given
that it's highly unlikely that anyone would now suddenly want
'--enable-frame-pointer' as the default for any kind of GNU system, I'm
changing the default back for GNU systems, to match that of a 'target_os' of
'linux* | darwin[8912]*'.

	gcc/
	PR target/89221
	* configure.ac (--enable-frame-pointer): Disable by default for
	GNU systems.
	* configure: Regenerate.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@271028 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 7 +++
 gcc/configure| 4 ++--
 gcc/configure.ac | 4 ++--
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 37447f854c0..ea96146b5b8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2019-05-09  Thomas Schwinge  
+
+	PR target/89221
+	* configure.ac (--enable-frame-pointer): Disable by default for
+	GNU systems.
+	* configure: Regenerate.
+
 2019-05-09  Alan Modra  
 
 	PR target/89271
diff --git a/gcc/configure b/gcc/configure
index 08cce6f1980..947d263a617 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -12197,8 +12197,8 @@ if test "${enable_frame_pointer+set}" = set; then :
 else
 
 case $target_os in
-linux* | darwin[8912]*)
-  # Enable -fomit-frame-pointer by default for Linux and Darwin with DWARF2.
+linux* | gnu* | darwin[8912]*)
+  # Enable -fomit-frame-pointer by default for these systems with DWARF2.
   enable_frame_pointer=no
   ;;
 *)
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 7c526b9ada4..bfcdf526e44 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1884,8 +1884,8 @@ AC_ARG_ENABLE(frame-pointer,
 		[enable -fno-omit-frame-pointer by default for x86])], [],
 [
 case $target_os in
-linux* | darwin[[8912]]*)
-  # Enable -fomit-frame-pointer by default for Linux and Darwin with DWARF2.
+linux* | gnu* | darwin[[8912]]*)
+  # Enable -fomit-frame-pointer by default for these systems with DWARF2.
   enable_frame_pointer=no
   ;;
 *)
-- 
2.17.1



signature.asc
Description: PGP signature

Re: [gnu-soc] GSoC org application 2019

[Thomas Schwinge]

Hi Joan!

On Wed, 13 Mar 2019 19:51:18 +0100, Joan Lledó  wrote:
> Missatge de Thomas Schwinge  del dia dc., 13 de
> març 2019 a les 19:42:
> > > https://www.gnu.org/software/soc-projects/ideas.html
> >
> > For GNU Hurd, please copy the stanza from
> > <https://www.gnu.org/software/soc-projects/ideas-2017.html>.
> 
> How may I do it? I don't see any edit link

Nothing for you to do there; Giuseppe or another GNU GSoC web pages
maintainer needs to do that.  Sorry for the confusion.


Grüße
 Thomas

Re: [gnu-soc] GSoC org application 2019

[Thomas Schwinge]

Hi!

On Mon, 21 Jan 2019 15:37:33 +0100, Giuseppe Scrivano  wrote:
> we need to check our ideas page.  As a starting point I've used the same
> page from the last year, some of them must be dropped.
> 
> Could each project review the ideas page (if you still get 404 give it
> some time to the server to sync)?
> 
> https://www.gnu.org/software/soc-projects/ideas.html

For GNU Hurd, please copy the stanza from
.  (..., and
we shall update our project ideas page.)


And, I noticed at the beginning of the page that this says "GNU's
participation in Google Summer of Code 2018", which should be "2019".


Grüße
 Thomas

Re: [gnu-soc] GSoC org application 2019

[Thomas Schwinge]

Hi Joan!

On Wed, 13 Mar 2019 18:41:54 +0100, Joan Lledó  wrote:
> Missatge de Thomas Schwinge  del dia dc., 13
> de març 2019 a les 12:22:
> > Would anybody be available as a mentor for anything related to GNU Hurd,
> 
> I'm considering it.

Oh, great, thanks!  I'll thus request a link to our (somewhat outdated;
please anyone help clean up) list of project ideas to be included on the
main GNU project ideas page.

(I'll also sync the wiki to the GNU Hurd web pages -- long overdue...)

> How much time would it take? do you think it's
> possible to combine it with a full-time job?

That completely depends on the student.  In general, yes, it ought to be
possible.  We have to carefully assess whether any student applying (if
any) is a match to the mentoring time you'll have available.  That means
to start discussions early, and let the students show that they're a fit
for the task you'd like to mentor, within limits, of course, because
they'll typically also have other commitments right now.


Grüße
 Thomas

Re: [gnu-soc] GSoC org application 2019

[Thomas Schwinge]

Hi!

It's that time of the year again, Google Summer of Code:

On Mon, 21 Jan 2019 15:37:33 +0100, Giuseppe Scrivano  wrote:
> jema...@gnu.org (Jose E. Marchesi) writes:
> 
> > GNU is applying as usual this year.
> > We will notify here with details.

..., and got accepted:
.


Would anybody be available as a mentor for anything related to GNU Hurd,
and/or the other way round: anybody reading here intending to apply as a
student?

If we got a mentor, we should then...

> we need to check our ideas page.  As a starting point I've used the same
> page from the last year, some of them must be dropped.
> 
> Could each project review the ideas page (if you still get 404 give it
> some time to the server to sync)?
> 
> https://www.gnu.org/software/soc-projects/ideas.html

... update this page to get us listed.


Grüße
 Thomas


signature.asc
Description: PGP signature

[gdb, hurd] Adjust to Hurd "proc" interface changes (was: proc_task2proc prototype change)

[Thomas Schwinge]

Hi!

On Tue, 06 Jun 2017 08:49:16 +0200, Justus Winter  wrote:
> David Michael  writes:
> > On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter  wrote:
> >> [...]

> > The reply
> > functions still have mach_port_poly_t, though, and they are used by
> > GDB.  Is that correct?
> 
> Oh wow, a server for the reply part of a protocol.  Odd.  Well, I
> decided not to revert the change to the reply part so that it is
> consistent with how the reply of a server for the full protocol works.
> 
> > It will require something like the following to get GDB to compile due
> > to the changed generated definitions.
> > [...]
> >  ILL_RPC (S_proc_getmsgport_reply,
> >   mach_port_t reply_port, kern_return_t return_code,
> > - mach_port_t msgports)
> > + mach_port_t msgports, mach_msg_type_name_t msgportsPoly)

ACK, thanks; I pushed to GDB master the attached commit
8071c5ce78245eff43f9977a7c3ff8328f7486da '[gdb, hurd] Adjust to Hurd
"proc" interface changes'.

> Well, seeing that ILL_RPC is for unused procedures, it would be much
> easier to use MIGs "new" way of creating default server stubs that
> return a fixed value.  This can be done by #defining MIG_EOPNOTSUPP to
> some value while compiling the MIG-generated server stub.  Being a
> simpleroutine it doesn't really matter to what value, but EOPNOTSUPP
> seems to be a better choice than ILL_RPC's 0.

Thanks, we shall look into that later.


Grüße
 Thomas


>From 8071c5ce78245eff43f9977a7c3ff8328f7486da Mon Sep 17 00:00:00 2001
From: David Michael 
Date: Mon, 5 Jun 2017 17:35:11 -0700
Subject: [PATCH] [gdb, hurd] Adjust to Hurd "proc" interface changes

Hurd's commit baf7e5c8ce176aead15c2559952d8bdf0da41ffd "hurd: Use polymorphic
port types to return some rights" causes in the GDB build:

/usr/bin/ld: process_reply_S.o: in function `_Xproc_pid2proc_reply':
[...]/gdb/process_reply_S.c:754: undefined reference to `S_proc_pid2proc_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:730: undefined reference to `S_proc_pid2proc_reply'
/usr/bin/ld: process_reply_S.o: in function `_Xproc_task2proc_reply':
[...]/gdb/process_reply_S.c:589: undefined reference to `S_proc_task2proc_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:565: undefined reference to `S_proc_task2proc_reply'
/usr/bin/ld: process_reply_S.o: in function `_Xproc_getmsgport_reply':
[...]/gdb/process_reply_S.c:204: undefined reference to `S_proc_getmsgport_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:180: undefined reference to `S_proc_getmsgport_reply'
collect2: error: ld returned 1 exit status

	gdb/
	* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
	(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
---
 gdb/ChangeLog | 7 +++
 gdb/gnu-nat.c | 8 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index e427dda8a3..f2bbd77558 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,10 @@
+2019-02-14  David Michael  
+	Samuel Thibault  
+	Thomas Schwinge  
+
+	* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
+	(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
+
 2019-02-14  Thomas Schwinge  
 
 	* gnu-nat.c (gnu_write_inferior, parse_int_arg, _parse_bool_arg)
diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index 395b456ad7..53f23068a4 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -1880,17 +1880,19 @@ ILL_RPC (S_proc_setmsgport_reply,
 	 mach_port_t oldmsgport)
 ILL_RPC (S_proc_getmsgport_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
-	 mach_port_t msgports)
+	 mach_port_t msgports, mach_msg_type_name_t msgportsPoly)
 ILL_RPC (S_proc_pid2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_task2pid_reply,
 	 mach_port_t reply_port, kern_return_t return_code, pid_t pid)
 ILL_RPC (S_proc_task2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code,
+	 mach_port_t proc, mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_proc2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_pid2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code,
+	 mach_port_t proc, mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_getprocinfo_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
 	 int flags, procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,
-- 
2.19.2

Re: [pushed][PATCH v3 1/4] Extended-remote follow exec

[Thomas Schwinge]

Hi!

On Fri, 17 Feb 2017 16:45:01 +, Pedro Alves  wrote:
> Only noticed this patch now.

Heh, and I've only now gotten back to completing this.  ;-)

> > On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
> > (I'm aware that there is other PATH_MAX usage in GDB sources, which we
> > ought to fix at some point, for example in gdbserver -- which is not yet
> > enabled for GNU/Hurd.)
> > 
> > OK to push the following?  (Similar to Svante's patch in
> > <https://bugs.debian.org/834575>.)
> 
> 
> > 
> > --- gdb/remote.c
> > +++ gdb/remote.c
> > @@ -6927,7 +6927,6 @@ Packet: '%s'\n"),
> >   else if (strprefix (p, p1, "exec"))
> > {
> >   ULONGEST ignored;
> > - char pathname[PATH_MAX];
> >   int pathlen;
> >  
> >   /* Determine the length of the execd pathname.  */
> > @@ -6936,11 +6935,12 @@ Packet: '%s'\n"),
> >  
> >   /* Save the pathname for event reporting and for
> >  the next run command.  */
> > + char *pathname = (char *) xmalloc (pathlen + 1);
> >   hex2bin (p1, (gdb_byte *) pathname, pathlen);
> >   pathname[pathlen] = '\0';
> 
> 
> hex2bin can throw, so wrap with a cleanup:
> 
>   char *pathname = (char *) xmalloc (pathlen + 1);
>   struct cleanup *old_chain = make_cleanup (xfree, pathname);
> hex2bin (p1, (gdb_byte *) pathname, pathlen);
> pathname[pathlen] = '\0';
>   discard_cleanups (old_chain);
> 
> OK with that change.

Thanks; pushed to master the attached commit
b671c7fb21306ce125717a44c30a71686bd24db1 "[gdb, hurd] Avoid using
'PATH_MAX' in 'gdb/remote.c'".


Grüße
 Thomas


>From b671c7fb21306ce125717a44c30a71686bd24db1 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 17 Feb 2017 16:45:01 +
Subject: [PATCH] [gdb, hurd] Avoid using 'PATH_MAX' in 'gdb/remote.c'

..., which is not defined in GNU/Hurd systems, and so commit
94585166dfea8232c248044f9f4b1c217dc4ac2e "Extended-remote follow-exec" caused:

[...]/gdb/remote.c: In member function 'void remote_target::remote_parse_stop_reply(const char*, stop_reply*)':
[...]/gdb/remote.c:7343:22: error: 'PATH_MAX' was not declared in this scope
char pathname[PATH_MAX];
  ^~~~

	gdb/
	* remote.c (remote_target::remote_parse_stop_reply): Avoid using
	'PATH_MAX'.
---
 gdb/ChangeLog | 6 ++
 gdb/remote.c  | 6 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index f2bbd77558..bb27f74de1 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-14  Thomas Schwinge  
+	Pedro Alves  
+
+	* remote.c (remote_target::remote_parse_stop_reply): Avoid using
+	'PATH_MAX'.
+
 2019-02-14  David Michael  
 	Samuel Thibault  
 	Thomas Schwinge  
diff --git a/gdb/remote.c b/gdb/remote.c
index 18e678d07a..85af01e4b7 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -7340,7 +7340,6 @@ Packet: '%s'\n"),
 	  else if (strprefix (p, p1, "exec"))
 	{
 	  ULONGEST ignored;
-	  char pathname[PATH_MAX];
 	  int pathlen;
 
 	  /* Determine the length of the execd pathname.  */
@@ -7349,11 +7348,14 @@ Packet: '%s'\n"),
 
 	  /* Save the pathname for event reporting and for
 		 the next run command.  */
+	  char *pathname = (char *) xmalloc (pathlen + 1);
+	  struct cleanup *old_chain = make_cleanup (xfree, pathname);
 	  hex2bin (p1, (gdb_byte *) pathname, pathlen);
 	  pathname[pathlen] = '\0';
+	  discard_cleanups (old_chain);
 
 	  /* This is freed during event handling.  */
-	  event->ws.value.execd_pathname = xstrdup (pathname);
+	  event->ws.value.execd_pathname = pathname;
 	  event->ws.kind = TARGET_WAITKIND_EXECD;
 
 	  /* Skip the registers included in this packet, since
-- 
2.19.2

Re: [PATCH] - hurd pci-arbiter: remove embedded pciaccess code

[Thomas Schwinge]

Hi!

On Sun, 11 Nov 2018 13:14:59 +1100, Damien Zammit  wrote:
> On 11/11/18 13:05, Samuel Thibault wrote:
> > Do you know how your copyright assignment is going, so I can commit it?
> 
> Haven't heard anything since I sent through my request.

This has yesterday been reported as completed in email with "Subject:
[gnu.org #1332514] Damien Zammit HURD MACH LIBC GRUB".

Thanks!


Grüße
 Thomas

Re: Documentation writer

[Thomas Schwinge]

Hi!

Reposting this, so that "evergetis" can actually see the answer, when not
(yet?) subscribed to the bug-hurd mailing list.  (It's good practice to
not strip off recipients when replying.)

Thanks for the offer to help with documentation, and thanks Joshua for
guidance!

For reference (... but I have not reviewed):

On Mon, 03 Dec 2018 12:57:30 -0500, Joshua Branson  wrote:
> everge...@csd.auth.gr writes:
> 
> > Hello! I am interested in helping you write the documentation for The  GNU 
> > Hurd.
> > I am a pre graduate student and it's going to be my project for a  class. I 
> > would be more than happy to contribute!
> 
> Hello!
> 
> There's several ways that you could help.
> 
> The wiki would be a pretty great place to start!  And relatively easy.
> 
> This web page gives an overview about how to contribute to the online
> wiki.
> 
> https://www.gnu.org/software/hurd/contributing/web_pages.html
> 
> Send your patches to bug-hurd@gnu.org.  No one uses the web-hurd mailing
> list.
> 
> Some things you could do:
> 
> https://notabug.org/jbranso/cheatsheets/src/master/hurd.org#wiki
> 
> https://notabug.org/jbranso/cheatsheets/src/master/hurd.org#copyread-the-arch-hurd-installation-page-somewhere--its-got-lots-of-good-details
> 
> I made a video a while ago showing you how to edit the wiki:
> 
> https://www.youtube.com/watch?v=56JLJvzUkQo
> 
> 
> You might also look into editing the official Hurd documentation.
> 
> https://www.gnu.org/software/hurd/doc/hurd_toc.html#SEC_Contents
> 
> You could try to change this section:
> 
> https://www.gnu.org/software/hurd/doc/hurd_4.html#SEC18
> 
> The Hurd no longer uses the libthreads.  Instead we use libpthreads.
> 
> 
> Maybe my online cheatsheet would be helpful to try to understand some
> hurd concepts:
> 
> https://notabug.org/jbranso/cheatsheets/src/master/hurd.org


Grüße
 Thomas

Re: [PATCH] build: Distribute tarball compressed with xz instead of bzip2

[Thomas Schwinge]

Hi!

On Tue,  6 Nov 2018 02:47:53 +0100, Guillem Jover  wrote:
> * Makefile (dist): Change bz2 to xz.
> (%.xz): Add target.
> (%.bz2): Remove target.

Curious: why a) use "xz" instead of what we got before, b) move from
"bz2" to "xz" instead of offering both (like we continue to do for "gz")?


Grüße
 Thomas


> ---
>  Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index c0aa59a0e..6288a1573 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -83,7 +83,7 @@ dist-version := $(shell cd $(top_srcdir)/ && 
> $(git_describe))
>  
>  .PHONY: dist
>  ifdef configured
> -dist: $(foreach Z,bz2 gz,$(dist-version).tar.$(Z))
> +dist: $(foreach Z,xz gz,$(dist-version).tar.$(Z))
>  else
>  dist:
>   @echo >&2 'Cannot build a distribution from an unconfigured tree.'
> @@ -238,8 +238,8 @@ install-headers: $(addsuffix 
> -install-headers,$(lib-subdirs) \
>  TAGS: $(addsuffix -TAGS,$(working-prog-subdirs) $(lib-subdirs))
>   etags -o $@ $(patsubst %-TAGS,-i %/TAGS,$^)
>  
> -%.bz2: %
> - bzip2 -9 < $< > $@
> +%.xz: %
> + xz < $< > $@
>  
>  %.gz: %
>   gzip -9n < $< > $@
> -- 
> 2.19.1.1182.g4ecb1133ce

Re: Cannot easily contribute to the wiki

[Thomas Schwinge]

Hi!

On Thu, 27 Sep 2018 18:42:08 -0400, Joshua Branson  wrote:
> "./render_locally".
> 
> $ ymlfront: failed to use YAML::Syck

Nothing else get printed?

> Luckily Parabola packages perl-yaml-syck!  But after I ran installed
> perl-yaml-syck, I still got the same error:
> 
> $ ymlfront: failed to use YAML::Syck
> 
> So I rebooted and tried again.   Same error:
> 
> $ ymlfront: failed to use YAML::Syck
> 
> 
> Granted, on my parabola machine, I'm not sure if I have all of the
> dependancies.  Mainly the wiki says to use apt-get, which I don't have.
> 
> $ apt-get install ikiwiki libyaml-syck-perl markdown libsearch-xapian-perl 
> texinfo
> 
> 
> Here's the dependancies I know I have:
> 
> [joshua@dobby hurd-web]$ pacman -Q markdown texinfo perl-yaml-syck
> discount 2.2.4-1
> texinfo 6.5-1
> perl-yaml-syck 1.30-5

What does the following print?

$ perl -e 'use YAML::Syck' && echo OK


I do remember commit 178b9e4a14e8ea6fa415c3c36461e41da8434694 "ymlfront:
Force use of YAML::Syck", but that shouldn't cause any problems if the
relevant Perl packages are properly installed.  You might try to
temporarily revert that one, though.

Or, temporarily disable (some of) these plugins, see "ikiwiki.setup".
You should still be able to "render_locally", just some information will
be missing on a few pages.


> So since my Parabola GNU/Linux machine didn't work, I thought I'd try
> the Hurd vm I have.

How do you start the VM?

> Then I booted up my Hurd VM and tried git pulling.
> 
>  fatal: Unable to look up darnassus.sceen.net (port 9418) (Temporary failure 
> in n
>ame resolution)

Same when pulling from savannah.gnu.org, probably?

> I also got this error as the vm was booting:
> ip up: failed to bring up /dev/eth0

Does the information from
<20180922084542.7v26lpgphexf52vn@var.youpi.perso.aquilenet.fr">http://mid.mail-archive.com/20180922084542.7v26lpgphexf52vn@var.youpi.perso.aquilenet.fr>
help by any chance?


> So, I'm kind of stuck at the moment.  :(

Well, on the contrary, there certainly are enough items here that can be
investigated.  :-)


Grüße
 Thomas

Re: Cannot easily contribute to the wiki

[Thomas Schwinge]

Hi!

On Wed, 26 Sep 2018 16:36:44 -0400, Joshua Branson  wrote:
> Thomas Schwinge  writes:
> > I'm aware of one problem that is seen with "recent" verions of Perl
> > (don't know when exactly this started), which indeed makes the "getfield"
> > plugin fail to load:
> >
> > $ ./render_locally 
> > Failed to load plugin IkiWiki::Plugin::getfield: Unescaped left brace 
> > in regex is illegal here in regex; marked by <-- HERE in m/{{ <-- HERE 
> > \$([-\w/]+#)?[-\w]+}}/ at [...]/.library/IkiWiki/Plugin/getfield.pm line 68.
> > Compilation failed in require at (eval 94) line 1.
> > BEGIN failed--compilation aborted at (eval 94) line 1.
> >
> 
> This is pretty the exact issue that I had.  :)
> 
> 
> > (This, or something similar, also happens when pushing to darnassus.)
> >
> > I already have identified a fix, and will push that in the next days.

I now pushed the attached to address this.


Please fetch and try again.


Grüße
 Thomas


>From 6a870e98d7f94402e83c02e9d7dfffb15f9013e4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 26 Sep 2018 22:20:34 +0200
Subject: [PATCH] Resolve incompatibility in "getfield" and "texinfo" plugins

... seen with recent versions of Perl:

Failed to load plugin IkiWiki::Plugin::getfield: Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/{{ <-- HERE \$([-\w/]+#)?[-\w]+}}/ at [...]/.library/IkiWiki/Plugin/getfield.pm line 68.
Compilation failed in require at (eval 94) line 1.
BEGIN failed--compilation aborted at (eval 94) line 1.
---
 .library/IkiWiki/Plugin/getfield.pm | 12 ++--
 .library/IkiWiki/Plugin/texinfo.pm  |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/.library/IkiWiki/Plugin/getfield.pm b/.library/IkiWiki/Plugin/getfield.pm
index 971e7ec..fb876f3 100644
--- a/.library/IkiWiki/Plugin/getfield.pm
+++ b/.library/IkiWiki/Plugin/getfield.pm
@@ -65,13 +65,13 @@ sub do_filter (@) {
 my $page_type=pagetype($page_file);
 if (defined $page_type)
 {
-	while ($params{content} =~ /{{\$([-\w\/]+#)?[-\w]+}}/)
+	while ($params{content} =~ /\{\{\$([-\w\/]+#)?[-\w]+\}\}/)
 	{
 	# substitute {{$var}} variables (source-page)
-	$params{content} =~ s/{{\$([-\w]+)}}/get_field_value($1,$page)/eg;
+	$params{content} =~ s/\{\{\$([-\w]+)\}\}/get_field_value($1,$page)/eg;
 
 	# substitute {{$page#var}} variables (source-page)
-	$params{content} =~ s/{{\$([-\w\/]+)#([-\w]+)}}/get_other_page_field_value($2,$page,$1)/eg;
+	$params{content} =~ s/\{\{\$([-\w\/]+)#([-\w]+)\}\}/get_other_page_field_value($2,$page,$1)/eg;
 	}
 }
 
@@ -79,12 +79,12 @@ sub do_filter (@) {
 $page_type=pagetype($page_file);
 if (defined $page_type)
 {
-	while ($params{content} =~ /{{\+\$([-\w\/]+#)?[-\w]+\+}}/)
+	while ($params{content} =~ /\{\{\+\$([-\w\/]+#)?[-\w]+\+\}\}/)
 	{
 	# substitute {{+$var+}} variables (dest-page)
-	$params{content} =~ s/{{\+\$([-\w]+)\+}}/get_field_value($1,$destpage)/eg;
+	$params{content} =~ s/\{\{\+\$([-\w]+)\+\}\}/get_field_value($1,$destpage)/eg;
 	# substitute {{+$page#var+}} variables (source-page)
-	$params{content} =~ s/{{\+\$([-\w\/]+)#([-\w]+)\+}}/get_other_page_field_value($2,$destpage,$1)/eg;
+	$params{content} =~ s/\{\{\+\$([-\w\/]+)#([-\w]+)\+\}\}/get_other_page_field_value($2,$destpage,$1)/eg;
 	}
 }
 
diff --git a/.library/IkiWiki/Plugin/texinfo.pm b/.library/IkiWiki/Plugin/texinfo.pm
index 8c65116..0950fb6 100644
--- a/.library/IkiWiki/Plugin/texinfo.pm
+++ b/.library/IkiWiki/Plugin/texinfo.pm
@@ -107,7 +107,7 @@ sub filter (@)
 # ``Render'' by hand some stuff that is commonly found in this section.
 if (defined $copyright{$page})
 {
-	$copyright{$page} =~ s/\@copyright{}/©/g;
+	$copyright{$page} =~ s/\@copyright\{\}/©/g;
 }
 if (defined $license{$page})
 {
-- 
1.9.1

Re: Cannot easily contribute to the wiki

[Thomas Schwinge]

Hi!

On Mon, 24 Sep 2018 11:19:42 -0400, Joshua Branson  wrote:
> A few years ago I had the Hurd wiki cloned locally, and I could rather
> trivially set it up.  However, following the online guide a few days
> ago, I'm running into some issues.
> 
> https://www.gnu.org/software/hurd/contributing/web_pages.html
> 
> I've cloned the repo.  I've run
> 
> $ apt-get install ikiwiki libyaml-syck-perl markdown
> libsearch-xapian-perl texinfo
> 
> Neither of these commands work in the web pages directory:
> 
>  ikiwiki --setup ikiwiki.setup
> 
> ./render_locally
> 
> 
> They both fail with "Failed to load plugin, Ikiwiki::Plugin::field".

Please always quote the exact log what you did and what happened;
copy'n'paste from your terminal.

> Basically getting all of ikiwiki's plugins needed to run the hurd wiki
> is a bit of a pain.

That's why these non-standard "field" etc. plugins are shipped inside the
Hurd "web" repository, see ".library/IkiWiki/Plugin/".

> This is not a complaint just an observation and a request for help.

Thanks for reporting.


I'm aware of one problem that is seen with "recent" verions of Perl
(don't know when exactly this started), which indeed makes the "getfield"
plugin fail to load:

$ ./render_locally 
Failed to load plugin IkiWiki::Plugin::getfield: Unescaped left brace in 
regex is illegal here in regex; marked by <-- HERE in m/{{ <-- HERE 
\$([-\w/]+#)?[-\w]+}}/ at [...]/.library/IkiWiki/Plugin/getfield.pm line 68.
Compilation failed in require at (eval 94) line 1.
BEGIN failed--compilation aborted at (eval 94) line 1.

(This, or something similar, also happens when pushing to darnassus.)

I already have identified a fix, and will push that in the next days.


Grüße
 Thomas

Re: Fwd: The GNU C Library version 2.28 is now available

[Thomas Schwinge]

Hi!

"By the way": very much yay! for "Building and running on GNU/Hurd
systems now works without out-of-tree patches".  Big thank you to Samuel
for driving this effort!  :-D


On Tue, 14 Aug 2018 22:18:53 +0200, Samuel Thibault  
wrote:
> David Michael, le mer. 01 août 2018 18:59:25 -0400, a ecrit:
> > On Wed, Aug 1, 2018 at 6:10 PM, Samuel Thibault  
> > wrote:
> > > For more invasive changes, it would make sense to have a
> > > branch in the hurd repo with normal, non-topgit, cherry-picks.

ACK.  Though, we should consider: who will be using that branch, that is,
who are we maintaining it for?

> > Okay, that makes sense.  I'd be interested to try such a branch and
> > see how it works out (once new Hurd patches are available, of course).
> > If you would like help maintaining it, I'm not currently in the
> > Savannah project, but my username is dm0 there in case it can be given
> > permission.  I'd assume the branch would follow the usual rule of
> > other projects' stable branches, where only cherry-picks of patches
> > already applied in master are allowed.
> 
> Indeed.
> 
> Thomas, could you add his login so he can help with it?

Done, thanks!


Grüße
 Thomas

chmod on fifos (was: [SCM] Web pages branch, master, updated. b9b5d1350ac648a4a654a00d1c0abda6dcb0ca29)

[Thomas Schwinge]

Hi Samuel!

On Sun, 13 Sep 2015 09:33:22 +, Samuel Thibault 
 wrote:
> commit b9b5d1350ac648a4a654a00d1c0abda6dcb0ca29
> Author: Samuel Thibault 
> Date:   Sun Sep 13 11:33:17 2015 +0200
> 
> Mention issue with fifo perms

That's: "Fix chmod on fifos: mkfifo foo ; sudo chmod g+w foo".

Stating that "The problem wasn't described. I executed the command
successfully. Seems fixed to me now", this has "recently" been removed by
"castilma" in commit 1523d18a5811c15c0d45e6162c1ba8ce7f794c1f -- via the
darnassus ikiwiki web interface, with author and commit date "Thu Sep 30
15:21:44 2032 +0200".  ;-)

If that's not correct, please put it back, with additional information.


Grüße
 Thomas

Re: GSoC 2018

[Thomas Schwinge]

Hi!

On Wed, 28 Feb 2018 12:39:15 +0100, I wrote:
> I did register with GNU to be a mentor so that I get access
> to the GSoC web page, and I'll check from time to time if any
> Hurd-related applications come in.

There are none.


Grüße
 Thomas

GSoC 2018 (was: GSoC 2018: Microkernel devroom)

[Thomas Schwinge]

Hi!

On Tue, 9 Jan 2018 22:59:46 +0100, Samuel Thibault  
wrote:
> Jakub Jermář, on ven. 05 janv. 2018 08:57:02 +0100, wrote:
> > another year of GSoC started and the mentor organization application
> > period is on until January 23 [0]. The question on the table is: would
> > Hurd like to participate under the Microkernel devroom [1] as it did
> > (very successfully) last year?

The Microkernel devroom -- unfortunately! -- did not get accepted by
Google for GSoC 2018.  :-(


The Hurd can still participate under the GNU umbrella, but...

> Will anybody be able to mentor students?

... we'll need mentors for that.  I'll wait if somebody speaks up to
commit to that, and only then ask to again get us listed on
.

> (I don't think I will have the time to)

Neither will I.  :-/

Nevertheless, I did register with GNU to be a mentor so that I get access
to the GSoC web page, and I'll check from time to time if any
Hurd-related applications come in.


Grüße
 Thomas

Re: Upstreaming the glibc Hurd port

[Thomas Schwinge]

Hi!

On Fri, 19 Jan 2018 13:08:01 +, Joseph Myers <jos...@codesourcery.com> 
wrote:
> On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> > > [build-many-glibcs.py]

> Do you have advice on versions to use of mig / gnumach / hurd?
> 
> Currently, build-many-glibcs.py uses (by default) release versions of most 
> components other than glibc itself, release branches for gcc / binutils.  
> Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd 
> be used for building current glibc for Hurd, or is it preferable or 
> necessary to use newer development versions of those components?

The current releases should generally be fine, yes.

(This reminds me that I wanted to publish new GNU Mach, MIG, Hurd,
libpthread releases, but no need for you to wait for these, as far as I
know.)


Grüße
 Thomas

Re: Upstreaming the glibc Hurd port

[Thomas Schwinge]

Hi Joseph!

On Fri, 19 Jan 2018 00:34:42 +, Joseph Myers  
wrote:
> On Fri, 19 Jan 2018, Samuel Thibault wrote:
> 
> > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote:
> > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise 
> > > there will be more to get it into a buildable state, e.g. the actual 
> > > libpthread implementation).
> > 
> > What I have pushed is basically only missing the libpthread
> > implementation, so you already have an idea of the minimal set of
> > modifications to get something building (and IIRC essentially passing
> > the testsuite).
> 
> I'd still like to have the libpthread implementation there (with a view to 
> seeing if I can get build-many-glibcs.py working for Hurd with this branch 

Many thanks for your offer!  As far as I'm aware indeed nobody from the
Hurd team has spent time on that yet.

> - if the branch has sources that build for Hurd, I should have some chance 
> of using 
> https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/cross-gnu?h=cross-gnu/master
>  
> to figure out how to do the Hurd-specific pieces that will need adding to 
> build-many-glibcs.py).

Beware that this script is from many years ago -- from times before my
dear CodeSourcery colleagues taught be how to ;-) properly build
cross-compilers.  But yes, cross-gnu did work back then.

Another thing to look into nowadays is David's (CCed) gnuxc,
<87r3vaw4os.fsf@gmail.com">http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
a Hurd distro",  "GNU OS Cross-Compiler".
(I have not yet looked into that one myself.)

And, the Guix/Hurd effort also is capable of cross-compilation, as far as
I remember.  But probably cross-gnu/gnuxc will already give you enough
pointers of what needs to be done.


Grüße
 Thomas

Re: Hurd lecture

[Thomas Schwinge]

Hi Brent!

On Thu, 18 Jan 2018 14:08:17 -0500, "Brent W. Baccala"  
wrote:
> FYI, I gave an hour and a half Hurd lecture yesterday at Catholic
> University in Washington, D.C.
> 
> I put a screencast of the lecture on youtube: [...]

Great, I'll be sure to view that!

> Could we add that to the collection of presentations that we've got on the
> documentation page?

If you'd like to, you can add it yourself using the wiki interface at
, or even just as a
patch to the web pages repository,
.  Or, if
you prefer, I'll take care of adding it later on.


Grüße
 Thomas

Re: Upstreaming the glibc Hurd port

[Thomas Schwinge]

Hi!

Despite my good intentions, in the past year (or even longer...) I failed
to allocate sufficient time to do any substantial work on the Hurd side,
but I'll now allocate time to at least help with...

On Thu, 18 Jan 2018 14:57:58 +0100, Samuel Thibault  
wrote:
> Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +, wrote:
> > All the usual coding standards of course apply,
> 
> And that's were I haven't received help so far.

... that.  (Plus the GDB stuff I promised to look into.)

> I can pile-commit what we currently have, with all the XXXs, FIXMEs,
> etc., if that can help the glibc side.

I'm not sure if that's a useful thing to spend time on, right now.  I
think it'll be better if we first integrate into glibc upstream the
changes that are non-controversial on our own side, which only touch Hurd
code, etc.  Then, for the rest of the changes, those which also touch
generic glibc code, we should then discuss these individually.

> But the actual discussion of changes is what takes time, and bug-hurd
> people have to actually help me with it (or at least unload from me the
> coding standards and ChangeLog parts) if they want it to happen fast
> enough.

ACK.


Grüße
 Thomas

Re: GSoC 2017: Porting LwIP to the Hurd

[Thomas Schwinge]

Hi!

On Fri, 17 Mar 2017 08:31:37 +0100, Joan Lledó  wrote:
> My name is Joan Lledó, I'm in the last year of my degree in CS at the
> Open University of Catalonia[1]. I'm interested in OS programming and,
> for now, I have only read theory and have made university exercises in
> ths field. That's why I see GSoC as a good chance to work in a real
> project and make contributions to it.

:-)

> I read your project ideas page and decided to take up the project
> "Hurdish TCP/IP stack"[2]. I chose [...]

That all looks reasonable to me.  (I do see the proposal submitted to
"Microkernel devroom".)


;-) Incidentally, I just found: "Announcement: replacing the MINIX 3
network stack [with a lwip-based variant]",
.


Grüße
 Thomas

Re: GSoC mentors

[Thomas Schwinge]

Hi!

On Fri, 10 Feb 2017 14:47:31 +0100, Justus Winter <jus...@gnupg.org> wrote:
> Thomas Schwinge <tho...@codesourcery.com> writes:
> 
> > Who will be available this year as a mentor for GSoC?
> 
> Me.

Danke!  :-)

So, you (as well as everyone else who'd like to be a mentor; but please
let us know) please register according to the instructions given in
<http://lists.gnu.org/archive/html/summer-of-code/2017-02/msg00026.html>,
id:"87lgsrgvi1@redhat.com" by sending email to <gscriv...@gnu.org>
and <jema...@gnu.org>.


Grüße
 Thomas

GSoC mentors

[Thomas Schwinge]

Hi!

Who will be available this year as a mentor for GSoC?


Grüße
 Thomas

Re: Time for another round of releases

[Thomas Schwinge]

Hi!

On Sat, 10 Dec 2016 18:35:16 +0100, Justus Winter <jus...@gnupg.org> wrote:
> Thomas Schwinge <tho...@codesourcery.com> writes:
> 
> > Will it be OK to move the release date towards end of November?  (Yay,
> > one more month for getting stuff finished for inclusion...)  ;'-\
> 
> Or two (mea culpa)

Heh, certainly not your fault!

> but I'm actually glad we did have a chance to merge
> some more stuff ;) So, anything else missing for Hurd 0.9?

:-) Seems we're good to go; planning for tomorrow.


I'll then set the GNU Hurd 0.10 etc. release dates for 2017-06, so that
we'll again have six months to get changes done.


Grüße
 Thomas

Re: [PATCH 2/4] Push pruning old threads down to the target

[Thomas Schwinge]

Hi!

On Thu,  2 Oct 2014 17:21:34 +0100, Pedro Alves <pal...@redhat.com> wrote:
> When GDB wants to sync the thread list with the target's [...]

> --- a/gdb/thread.c
> +++ b/gdb/thread.c

>  void
>  update_thread_list (void)
>  {
> -  prune_threads ();
> -  target_find_new_threads ();
> +  target_update_thread_list ();
>update_threads_executing ();
>  }

Pushed to master:

commit c752a4cccb99ba73f51eff74b394dcdcd26d4c59
Author: Thomas Schwinge <tho...@codesourcery.com>
Date:   Wed May 25 18:54:40 2016 +0200

Hurd: Adjust to changes to "push pruning old threads down to the target"

For "info threads", we currently run into:

$ gdb/gdb -q -nw -nx --batch -ex start -ex info\ threads bfd/doc/chew
Temporary breakpoint 1 at 0x80486e0: file 
../../../W._C._Handy/bfd/doc/chew.c, line 1535.
[New Thread 10656.5]

Thread 4 hit Temporary breakpoint 1, main (ac=1, av=0x102cd84) at 
../../../W._C._Handy/bfd/doc/chew.c:1535
1535{
  Id   Target Id Frame
  1bogus thread id 1 Can't fetch registers from thread bogus thread 
id 1: No such thread

Before commit e8032dde10b743253125d7defb5f5503b21c1d26,
gdb/thread.c:update_thread_list used to call prune_threads, after that 
change
it doesn't anymore, and we don't implement the to_update_thread_list target
method where the prune_threads call got moved.  For now, apply a fix, 
related
to commit c82f56d9d760a9b4034eeaac44f2f0fa5779ff69 "Hurd: Adjust to
startup-with-shell changes", which restores the previous behavior:

  Id   Target Id Frame
* 4Thread 10688.4main (ac=1, av=0x102cd84) at 
../../../W._C._Handy/bfd/doc/chew.c:1535
  5Thread 10688.50x0106096c in ?? () from 
/lib/i386-gnu/libc.so.0.3

Not perfect, but at least better.

gdb/
* gnu-nat.c (gnu_create_inferior): After startup_inferior, call
prune_threads.
---
 gdb/ChangeLog | 3 +++
 gdb/gnu-nat.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git gdb/ChangeLog gdb/ChangeLog
index 302eb6e..7fd5d32 100644
--- gdb/ChangeLog
+++ gdb/ChangeLog
@@ -1,5 +1,8 @@
 2016-12-09  Thomas Schwinge  <tho...@codesourcery.com>
 
+   * gnu-nat.c (gnu_create_inferior): After startup_inferior, call
+   prune_threads.
+
* inferior.c (print_selected_inferior): Avoid PATH_MAX usage.
 
 2016-12-08  Simon Marchi  <simon.mar...@ericsson.com>
diff --git gdb/gnu-nat.c gdb/gnu-nat.c
index 124574e..85a53b8 100644
--- gdb/gnu-nat.c
+++ gdb/gnu-nat.c
@@ -2163,6 +2163,8 @@ gnu_create_inferior (struct target_ops *ops,
 
   startup_inferior (START_INFERIOR_TRAPS_EXPECTED);
   inf->pending_execs = 0;
+  /* Get rid of the old shell threads.  */
+  prune_threads ();
 
   inf_validate_procinfo (inf);
   inf_update_signal_thread (inf);


Grüße
 Thomas

Re: [PATCH v3 1/2] Emit inferior, thread and frame selection events to all UIs

[Thomas Schwinge]

Hi!

On Sat, 24 Sep 2016 16:13:30 -0400, Simon Marchi  
wrote:
> --- a/gdb/inferior.c
> +++ b/gdb/inferior.c

> +void
> +print_selected_inferior (struct ui_out *uiout)
> +{
> +  char buf[PATH_MAX + 256];
> +  struct inferior *inf = current_inferior ();
> +
> +  xsnprintf (buf, sizeof (buf),
> +  _("[Switching to inferior %d [%s] (%s)]\n"),
> +  inf->num,
> +  inferior_pid_to_str (inf->pid),
> +  (inf->pspace->pspace_exec_filename != NULL
> +   ? inf->pspace->pspace_exec_filename
> +   : _("")));
> +  ui_out_text (uiout, buf);
> +}
> +

On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
(I'm aware that there is other PATH_MAX usage in GDB sources, which we
ought to fix at some point, for example in gdbserver -- which is not yet
enabled for GNU/Hurd.)

Unless I miss something, this issue could be addressed by simply using
ui_out_message instead of ui_out_text with a temporary "buf" -- OK to
push the following?

--- gdb/inferior.c
+++ gdb/inferior.c
@@ -556,17 +556,15 @@ inferior_pid_to_str (int pid)
 void
 print_selected_inferior (struct ui_out *uiout)
 {
-  char buf[PATH_MAX + 256];
   struct inferior *inf = current_inferior ();
 
-  xsnprintf (buf, sizeof (buf),
-_("[Switching to inferior %d [%s] (%s)]\n"),
-inf->num,
-inferior_pid_to_str (inf->pid),
-(inf->pspace->pspace_exec_filename != NULL
- ? inf->pspace->pspace_exec_filename
- : _("")));
-  ui_out_text (uiout, buf);
+  ui_out_message (uiout,
+ _("[Switching to inferior %d [%s] (%s)]\n"),
+ inf->num,
+ inferior_pid_to_str (inf->pid),
+ (inf->pspace->pspace_exec_filename != NULL
+  ? inf->pspace->pspace_exec_filename
+  : _("")));
 }
 
 /* Prints the list of inferiors and their details on UIOUT.  This is a


Grüße
 Thomas

Re: [pushed][PATCH v3 1/4] Extended-remote follow exec

[Thomas Schwinge]

Hi!

On Fri, 11 Sep 2015 11:38:15 -0700, Don Breazeal  wrote:
> Here is what I pushed.

> --- a/gdb/remote.c
> +++ b/gdb/remote.c

> @@ -6089,11 +6178,42 @@ Packet: '%s'\n"),
> event->ws.kind = TARGET_WAITKIND_VFORK_DONE;
> p = skip_to_semicolon (p1 + 1);
>   }
> +   else if (strncmp (p, "exec", p1 - p) == 0)
> + {
> +   ULONGEST ignored;
> +   char pathname[PATH_MAX];
> +   int pathlen;
> +
> +   /* Determine the length of the execd pathname.  */
> +   p = unpack_varlen_hex (++p1, );
> +   pathlen = (p - p1) / 2;
> +
> +   /* Save the pathname for event reporting and for
> +  the next run command.  */
> +   hex2bin (p1, (gdb_byte *) pathname, pathlen);
> +   pathname[pathlen] = '\0';
> +
> +   /* This is freed during event handling.  */
> +   event->ws.value.execd_pathname = xstrdup (pathname);
> +   event->ws.kind = TARGET_WAITKIND_EXECD;
> +
> +   /* Skip the registers included in this packet, since
> +  they may be for an architecture different from the
> +  one used by the original program.  */
> +   skipregs = 1;
> + }

On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
(I'm aware that there is other PATH_MAX usage in GDB sources, which we
ought to fix at some point, for example in gdbserver -- which is not yet
enabled for GNU/Hurd.)

OK to push the following?  (Similar to Svante's patch in
.)

--- gdb/remote.c
+++ gdb/remote.c
@@ -6927,7 +6927,6 @@ Packet: '%s'\n"),
  else if (strprefix (p, p1, "exec"))
{
  ULONGEST ignored;
- char pathname[PATH_MAX];
  int pathlen;
 
  /* Determine the length of the execd pathname.  */
@@ -6936,11 +6935,12 @@ Packet: '%s'\n"),
 
  /* Save the pathname for event reporting and for
 the next run command.  */
+ char *pathname = (char *) xmalloc (pathlen + 1);
  hex2bin (p1, (gdb_byte *) pathname, pathlen);
  pathname[pathlen] = '\0';
 
  /* This is freed during event handling.  */
- event->ws.value.execd_pathname = xstrdup (pathname);
+ event->ws.value.execd_pathname = pathname;
  event->ws.kind = TARGET_WAITKIND_EXECD;
 
  /* Skip the registers included in this packet, since


Grüße
 Thomas

Re: [PATCH v3 4/7] Per-inferior/Inferior-qualified thread IDs

[Thomas Schwinge]

Hi Simon!

On Wed, 7 Dec 2016 16:28:58 -0500, Simon Marchi <simon.mar...@ericsson.com> 
wrote:
> On 16-12-07 04:09 PM, Thomas Schwinge wrote:
> > commit 14f6890677849172a4b13779acd9089c9baa3a81
> > Author: Thomas Schwinge <tho...@codesourcery.com>
> > Date:   Tue May 24 19:36:57 2016 +0200
> > 
> > Hurd: Adjust to "Per-inferior/Inferior-qualified thread IDs" changes
> > 
> > [...]/gdb/gnu-nat.c: In function 'set_sig_thread_cmd':
> > [...]/gdb/gnu-nat.c:2973:7: warning: implicit declaration of 
> > function 'thread_id_to_pid' [-Wimplicit-function-declaration]
> >ptid_t ptid = thread_id_to_pid (atoi (args));
> >^
> > [...]/gdb/gnu-nat.c:2973:7: error: invalid initializer
> > 
> > That's commit 5d5658a1d3c3eb2a09c03f2f0662a1c01963c869, which renamed
> > `thread_id_to_pid` to `global_thread_id_to_ptid`.

> > --- gdb/gnu-nat.c
> > +++ gdb/gnu-nat.c
> > @@ -2964,7 +2964,7 @@ set_sig_thread_cmd (char *args, int from_tty)
> >  inf->signal_thread = 0;
> >else
> >  {
> > -  ptid_t ptid = thread_id_to_pid (atoi (args));
> > +  ptid_t ptid = global_thread_id_to_ptid (atoi (args));
> 
> I think your patch is better than the status quo, since it fixes the build.
> However, global_thread_id_to_ptid expects global thread numbers, which are
> nowadays only used in MI, never presented to the user in the CLI.  Since this
> is a CLI command, it should accept the inferior-qualified format instead.

Thanks for the review!

> Something similar to this should do the trick (I can't test it though):

> --- a/gdb/gnu-nat.c
> +++ b/gdb/gnu-nat.c
> @@ -2964,13 +2964,13 @@ set_sig_thread_cmd (char *args, int from_tty)
>  inf->signal_thread = 0;
>else
>  {
> -  ptid_t ptid = thread_id_to_pid (atoi (args));
> +  struct thread_info *tp = parse_thread_id (args, NULL)
> 
> -  if (ptid_equal (ptid, minus_one_ptid))
> +  if (tp == nullptr)
> error (_("Thread ID %s not known.  "
>  "Use the \"info threads\" command to\n"
>"see the IDs of currently known threads."), args);
> -  inf->signal_thread = inf_tid_to_thread (inf, ptid_get_lwp (ptid));
> +  inf->signal_thread = inf_tid_to_thread (inf, ptid_get_lwp (tp->ptid));
>  }
>  }

Thanks for the patch!  Actually, parse_thread_id will never return NULL
("Either a valid thread is returned, or an error is thrown."), so that
can be made even simpler.  (As also the parse_thread_id usage in
gdb/thread.c doesn't use ENDPTR to check for "junk" after the thread ID,
I don't see a need to do that here.)  ;-)

> If there's a more efficient/concise way to go from a thread_info* to a proc*, 
> we
> should probably use it, but I couldn't find one.

Indeed that seems to be the standard pattern.

I pushed the following to master:

commit c3187fa5cc72734e6fc766a85d657018c0516bad
Author: Simon Marchi <simon.mar...@ericsson.com>
Date:   Thu Dec 8 09:45:59 2016 +0100

Hurd: In the CLI, use parse_thread_id instead of global_thread_id_to_ptid

Follow-up to commit 14f6890677849172a4b13779acd9089c9baa3a81.
global_thread_id_to_ptid expects global thread numbers, which are nowadays 
only
used in MI, never presented to the user in the CLI.  Since this is a CLI
command, it should accept the inferior-qualified format instead.

gdb/
* gnu-nat.c (set_sig_thread_cmd): Use parse_thread_id instead of
global_thread_id_to_ptid.
---
 gdb/ChangeLog |  6 ++
 gdb/gnu-nat.c | 12 
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git gdb/ChangeLog gdb/ChangeLog
index 171d03a..2bd99f1 100644
--- gdb/ChangeLog
+++ gdb/ChangeLog
@@ -1,3 +1,9 @@
+2016-12-08  Simon Marchi  <simon.mar...@ericsson.com>
+   Thomas Schwinge  <tho...@codesourcery.com>
+
+   * gnu-nat.c (set_sig_thread_cmd): Use parse_thread_id instead of
+   global_thread_id_to_ptid.
+
 2016-12-08  Thomas Schwinge  <tho...@codesourcery.com>
 
* config/i386/i386gnu.mh (%_S.o %_U.o): Add "-x c" to
diff --git gdb/gnu-nat.c gdb/gnu-nat.c
index 5fd59a2..124574e 100644
--- gdb/gnu-nat.c
+++ gdb/gnu-nat.c
@@ -63,6 +63,7 @@ extern "C"
 #include "gdbcore.h"
 #include "gdbthread.h"
 #include "gdb_obstack.h"
+#include "tid-parse.h"
 
 #include "gnu-nat.h"
 #include "inf-child.h"
@@ -2975,19 +2976,14 @@ set_sig_thread_cmd (char *args, int from_tty)
 
   if (!args || (!isdigit (*args) && strcmp (args, "none") != 0))
 error (_("Illegal argument to \"set signal-th

[PATCH 4/5] Hurd, C++: kern_return_t vs. error_t

[Thomas Schwinge]

GNU/Hurd uses its own "typedef enum __error_t_codes error_t;"
([glibc]/sysdeps/mach/hurd/bits/errno.h), contrary to the default
"typedef int error_t;" ([glibc]/stdlib/errno.h).

The Mach/Hurd RPCs return kern_return_t values, for which, upon assigning them
to an error_t variable, GCC in C++ mode tells us "error: invalid conversion
from 'kern_return_t {aka int}' to 'error_t {aka __error_t_codes}'".  Instead of
casting all these RPC return values to "error_t", just use "kern_return_t"
variables:

gdb/
* gnu-nat.c (proc_get_exception_port, proc_set_exception_port)
(INF_RESUME_MSGPORT_RPC, proc_get_state, _proc_get_exc_port)
(proc_steal_exc_port, proc_restore_exc_port, make_proc)
(inf_startup, inf_set_pid, inf_validate_procinfo)
(inf_validate_task_sc, inf_set_traced, inf_validate_procs)
(inf_signal, inf_continue, gnu_wait, S_exception_raise_request)
(do_mach_notify_dead_name, S_proc_wait_reply)
(S_msg_sig_post_untraced_reply, S_msg_sig_post_reply)
(port_msgs_queued, gnu_read_inferior, gnu_write_inferior)
(gnu_find_memory_regions, steal_exc_port, thread_takeover_sc_cmd)
(flush_inferior_icache): Instead of "error_t" use "kern_return_t".
* i386-gnu-nat.c (fetch_fpregs, store_fpregs, i386_gnu_dr_get)
(i386_gnu_dr_set): Likewise.
---
 gdb/ChangeLog  | 14 
 gdb/gnu-nat.c  | 66 +++---
 gdb/i386-gnu-nat.c |  8 +++
 3 files changed, 51 insertions(+), 37 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index b40ac6f..a40eb29 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,19 @@
 2016-12-08  Thomas Schwinge  <tho...@codesourcery.com>
 
+   * gnu-nat.c (proc_get_exception_port, proc_set_exception_port)
+   (INF_RESUME_MSGPORT_RPC, proc_get_state, _proc_get_exc_port)
+   (proc_steal_exc_port, proc_restore_exc_port, make_proc)
+   (inf_startup, inf_set_pid, inf_validate_procinfo)
+   (inf_validate_task_sc, inf_set_traced, inf_validate_procs)
+   (inf_signal, inf_continue, gnu_wait, S_exception_raise_request)
+   (do_mach_notify_dead_name, S_proc_wait_reply)
+   (S_msg_sig_post_untraced_reply, S_msg_sig_post_reply)
+   (port_msgs_queued, gnu_read_inferior, gnu_write_inferior)
+   (gnu_find_memory_regions, steal_exc_port, thread_takeover_sc_cmd)
+   (flush_inferior_icache): Instead of "error_t" use "kern_return_t".
+   * i386-gnu-nat.c (fetch_fpregs, store_fpregs, i386_gnu_dr_get)
+   (i386_gnu_dr_set): Likewise.
+
* gnu-nat.c (set_task_pause_cmd, set_signals_cmd)
(set_exceptions_cmd): Add variants taking an "int arg" instead of
a "char *".  Make the "char *" variants use the former.
diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index 29bd9b9..ae4430d 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -113,8 +113,8 @@ void proc_abort (struct proc *proc, int force);
 struct proc *make_proc (struct inf *inf, mach_port_t port, int tid);
 struct proc *_proc_free (struct proc *proc);
 int proc_update_sc (struct proc *proc);
-error_t proc_get_exception_port (struct proc *proc, mach_port_t * port);
-error_t proc_set_exception_port (struct proc *proc, mach_port_t port);
+kern_return_t proc_get_exception_port (struct proc *proc, mach_port_t * port);
+kern_return_t proc_set_exception_port (struct proc *proc, mach_port_t port);
 static mach_port_t _proc_get_exc_port (struct proc *proc);
 void proc_steal_exc_port (struct proc *proc, mach_port_t exc_port);
 void proc_restore_exc_port (struct proc *proc);
@@ -133,7 +133,7 @@ int proc_trace (struct proc *proc, int set);
afterwards).  This effects INF's threads' resume_sc count.  */
 #define INF_RESUME_MSGPORT_RPC(inf, rpc_expr) \
   (inf_set_threads_resume_sc_for_signal_thread (inf) \
-   ? ({ error_t __e; \
+   ? ({ kern_return_t __e; \
inf_resume (inf); \
__e = INF_MSGPORT_RPC (inf, rpc_expr); \
inf_suspend (inf); \
@@ -367,7 +367,7 @@ proc_get_state (struct proc *proc, int will_modify)
   if (!proc->state_valid)
 {
   mach_msg_type_number_t state_size = THREAD_STATE_SIZE;
-  error_t err =
+  kern_return_t err =
thread_get_state (proc->port, THREAD_STATE_FLAVOR,
  (thread_state_t) >state, _size);
 
@@ -387,7 +387,7 @@ proc_get_state (struct proc *proc, int will_modify)
 
 
 /* Set PORT to PROC's exception port.  */
-error_t
+kern_return_t
 proc_get_exception_port (struct proc * proc, mach_port_t * port)
 {
   if (proc_is_task (proc))
@@ -397,7 +397,7 @@ proc_get_exception_port (struct proc * proc, mach_port_t * 
port)
 }
 
 /* Set PROC's exception port to PORT.  */
-error_t
+kern_return_t
 proc_set_exception_port (struct proc * proc, mach_port_t port)
 {
   proc_debug (proc, "setting exception 

[PATCH 3/5] Hurd, C++: Avoid "const char *" to "char *" casts

[Thomas Schwinge]

... by a bit of code refactoring:

gdb/
* gnu-nat.c (set_task_pause_cmd, set_signals_cmd)
(set_exceptions_cmd): Add variants taking an "int arg" instead of
a "char *".  Make the "char *" variants use the former.
(set_noninvasive_cmd): Also use the "int arg" variants.
---
 gdb/ChangeLog |  5 +
 gdb/gnu-nat.c | 39 ---
 2 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 8b43cd8..b40ac6f 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,10 @@
 2016-12-08  Thomas Schwinge  <tho...@codesourcery.com>
 
+   * gnu-nat.c (set_task_pause_cmd, set_signals_cmd)
+   (set_exceptions_cmd): Add variants taking an "int arg" instead of
+   a "char *".  Make the "char *" variants use the former.
+   (set_noninvasive_cmd): Also use the "int arg" variants.
+
* gnu-nat.c (gnu_create_inferior): Move nested "trace_me"
function...
(gnu_ptrace_me): ... here.
diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index 34fd6f1..29bd9b9 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -2792,12 +2792,12 @@ active_inf (void)
 
 
 static void
-set_task_pause_cmd (char *args, int from_tty)
+set_task_pause_cmd (int arg, int from_tty)
 {
   struct inf *inf = cur_inf ();
   int old_sc = inf->pause_sc;
 
-  inf->pause_sc = parse_bool_arg (args, "set task pause");
+  inf->pause_sc = arg;
 
   if (old_sc == 0 && inf->pause_sc != 0)
 /* If the task is currently unsuspended, immediately suspend it,
@@ -2806,6 +2806,12 @@ set_task_pause_cmd (char *args, int from_tty)
 }
 
 static void
+set_task_pause_cmd (char *args, int from_tty)
+{
+  set_task_pause_cmd (parse_bool_arg (args, "set task pause"), from_tty);
+}
+
+static void
 show_task_pause_cmd (char *args, int from_tty)
 {
   struct inf *inf = cur_inf ();
@@ -2991,11 +2997,11 @@ show_sig_thread_cmd (char *args, int from_tty)
 
 
 static void
-set_signals_cmd (char *args, int from_tty)
+set_signals_cmd (int arg, int from_tty)
 {
   struct inf *inf = cur_inf ();
 
-  inf->want_signals = parse_bool_arg (args, "set signals");
+  inf->want_signals = arg;
 
   if (inf->task && inf->want_signals != inf->traced)
 /* Make this take effect immediately in a running process.  */
@@ -3003,6 +3009,12 @@ set_signals_cmd (char *args, int from_tty)
 }
 
 static void
+set_signals_cmd (char *args, int from_tty)
+{
+  set_signals_cmd(parse_bool_arg (args, "set signals"), from_tty);
+}
+
+static void
 show_signals_cmd (char *args, int from_tty)
 {
   struct inf *inf = cur_inf ();
@@ -3015,15 +3027,20 @@ show_signals_cmd (char *args, int from_tty)
 }
 
 static void
-set_exceptions_cmd (char *args, int from_tty)
+set_exceptions_cmd (int arg, int from_tty)
 {
   struct inf *inf = cur_inf ();
-  int val = parse_bool_arg (args, "set exceptions");
 
   /* Make this take effect immediately in a running process.  */
   /* XXX */ ;
 
-  inf->want_exceptions = val;
+  inf->want_exceptions = arg;
+}
+
+static void
+set_exceptions_cmd (char *args, int from_tty)
+{
+  set_exceptions_cmd (parse_bool_arg (args, "set exceptions"), from_tty);
 }
 
 static void
@@ -3078,11 +3095,11 @@ static void
 set_noninvasive_cmd (char *args, int from_tty)
 {
   /* Invert the sense of the arg for each component.  */
-  char *inv_args = parse_bool_arg (args, "set noninvasive") ? "off" : "on";
+  int inv_arg = parse_bool_arg (args, "set noninvasive") ? 0 : 1;
 
-  set_task_pause_cmd (inv_args, from_tty);
-  set_signals_cmd (inv_args, from_tty);
-  set_exceptions_cmd (inv_args, from_tty);
+  set_task_pause_cmd (inv_arg, from_tty);
+  set_signals_cmd (inv_arg, from_tty);
+  set_exceptions_cmd (inv_arg, from_tty);
 }
 
 
-- 
2.10.2

[PATCH 5/5] Hurd, C++: Mach/Hurd headers and MIG stubs are not yet fit for C++

[Thomas Schwinge]

..., so handle these in "C" mode still:

gdb/
* config/i386/i386gnu.mh (%_S.o %_U.o): Add "-x c" to
"COMPILE.post".
* gnu-nat.c: #include Mach/Hurd headers before all others.  Wrap
Mach/Hurd headers and MIG stubs' prototypes in 'extern "C"'.
* i386-gnu-nat.c: Likewise.
---
 gdb/ChangeLog  |  6 ++
 gdb/config/i386/i386gnu.mh |  3 +++
 gdb/gnu-nat.c  | 35 ++-
 gdb/i386-gnu-nat.c | 14 +-
 4 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index a40eb29..171d03a 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,11 @@
 2016-12-08  Thomas Schwinge  <tho...@codesourcery.com>
 
+   * config/i386/i386gnu.mh (%_S.o %_U.o): Add "-x c" to
+   "COMPILE.post".
+   * gnu-nat.c: #include Mach/Hurd headers before all others.  Wrap
+   Mach/Hurd headers and MIG stubs' prototypes in 'extern "C"'.
+   * i386-gnu-nat.c: Likewise.
+
* gnu-nat.c (proc_get_exception_port, proc_set_exception_port)
(INF_RESUME_MSGPORT_RPC, proc_get_state, _proc_get_exc_port)
(proc_steal_exc_port, proc_restore_exc_port, make_proc)
diff --git a/gdb/config/i386/i386gnu.mh b/gdb/config/i386/i386gnu.mh
index 24e817e..070497f 100644
--- a/gdb/config/i386/i386gnu.mh
+++ b/gdb/config/i386/i386gnu.mh
@@ -32,6 +32,9 @@ MIGCOM = $(MIG) -cc cat - /dev/null
$(CPP) $(CPPFLAGS) $($*-MIGUFLAGS) -x c $< \
| $(MIGCOM) -sheader /dev/null -server /dev/null -user $*_U.c -header 
$*_U.h
 
+# MIG stubs are not yet ready for C++ compilation.
+%_S.o %_U.o : COMPILE.post += -x c
+
 NAT_GENERATED_FILES = notify_S.h notify_S.c \
process_reply_S.h process_reply_S.c \
msg_reply_S.h msg_reply_S.c msg_U.h msg_U.c \
diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index ae4430d..5fd59a2 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -20,14 +20,9 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
-#include "defs.h"
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
+/* Mach/Hurd headers are not yet ready for C++ compilation.  */
+extern "C"
+{
 #include 
 #include 
 #include 
@@ -48,6 +43,15 @@
 #include 
 
 #include 
+}
+
+#include "defs.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include "inferior.h"
 #include "symtab.h"
@@ -63,12 +67,16 @@
 #include "gnu-nat.h"
 #include "inf-child.h"
 
+/* MIG stubs are not yet ready for C++ compilation.  */
+extern "C"
+{
 #include "exc_request_S.h"
 #include "notify_S.h"
 #include "process_reply_S.h"
 #include "msg_reply_S.h"
 #include "exc_request_U.h"
 #include "msg_U.h"
+}
 
 static process_t proc_server = MACH_PORT_NULL;
 
@@ -1443,6 +1451,12 @@ struct inf *gnu_current_inf = 0;
multi-threaded, we don't bother to lock this.  */
 struct inf *waiting_inf;
 
+/* MIG stubs are not yet ready for C++ compilation.  */
+extern "C" int exc_server (mach_msg_header_t *, mach_msg_header_t *);
+extern "C" int msg_reply_server (mach_msg_header_t *, mach_msg_header_t *);
+extern "C" int notify_server (mach_msg_header_t *, mach_msg_header_t *);
+extern "C" int process_reply_server (mach_msg_header_t *, mach_msg_header_t *);
+
 /* Wait for something to happen in the inferior, returning what in STATUS.  */
 static ptid_t
 gnu_wait (struct target_ops *ops,
@@ -1458,11 +1472,6 @@ gnu_wait (struct target_ops *ops,
   struct proc *thread;
   struct inf *inf = gnu_current_inf;
 
-  extern int exc_server (mach_msg_header_t *, mach_msg_header_t *);
-  extern int msg_reply_server (mach_msg_header_t *, mach_msg_header_t *);
-  extern int notify_server (mach_msg_header_t *, mach_msg_header_t *);
-  extern int process_reply_server (mach_msg_header_t *, mach_msg_header_t *);
-
   gdb_assert (inf->task);
 
   if (!inf->threads && !inf->pending_execs)
diff --git a/gdb/i386-gnu-nat.c b/gdb/i386-gnu-nat.c
index add0aa4..77081b8 100644
--- a/gdb/i386-gnu-nat.c
+++ b/gdb/i386-gnu-nat.c
@@ -17,17 +17,21 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
+/* Mach/Hurd headers are not yet ready for C++ compilation.  */
+extern "C"
+{
+#include 
+#include 
+#include 
+#include 
+}
+
 #include "defs.h"
 #include "x86-nat.h"
 #include "inferior.h"
 #include "floatformat.h"
 #include "regcache.h"
 
-#include 
-#include 
-#include 
-#include 
-
 #include "i386-tdep.h"
 
 #include "gnu-nat.h"
-- 
2.10.2

[PATCH 1/5] Hurd, C++: Explicitly cast "void *"

[Thomas Schwinge]

C++ doesn't do implicit type conversions from "void *", so we have to...

gdb/
* i386-gnu-nat.c (i386_gnu_dr_set_control_one)
(i386_gnu_dr_set_addr_one): Explicitly cast "void *".
---
 gdb/ChangeLog  | 5 +
 gdb/i386-gnu-nat.c | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 61d1205..f68a787 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2016-12-08  Thomas Schwinge  <tho...@codesourcery.com>
+
+   * i386-gnu-nat.c (i386_gnu_dr_set_control_one)
+   (i386_gnu_dr_set_addr_one): Explicitly cast "void *".
+
 2016-12-07  Thomas Schwinge  <tho...@codesourcery.com>
 
* gnu-nat.c (set_sig_thread_cmd): Call global_thread_id_to_ptid
diff --git a/gdb/i386-gnu-nat.c b/gdb/i386-gnu-nat.c
index e14a181..c6c53ca 100644
--- a/gdb/i386-gnu-nat.c
+++ b/gdb/i386-gnu-nat.c
@@ -307,7 +307,7 @@ i386_gnu_dr_set (const struct i386_debug_state *regs, 
struct proc *thread)
 static void
 i386_gnu_dr_set_control_one (struct proc *thread, void *arg)
 {
-  unsigned long *control = arg;
+  unsigned long *control = (unsigned long *) arg;
   struct i386_debug_state regs;
 
   i386_gnu_dr_get (, thread);
@@ -337,7 +337,7 @@ struct reg_addr
 static void
 i386_gnu_dr_set_addr_one (struct proc *thread, void *arg)
 {
-  struct reg_addr *reg_addr = arg;
+  struct reg_addr *reg_addr = (struct reg_addr *) arg;
   struct i386_debug_state regs;
 
   i386_gnu_dr_get (, thread);
-- 
2.10.2

[PATCH 2/5] Hurd, C++: Avoid GNU C nested functions

[Thomas Schwinge]

..., which C++ doesn't allow, so...

gdb/
* gnu-nat.c (gnu_create_inferior): Move nested "trace_me"
function...
(gnu_ptrace_me): ... here.
---
 gdb/ChangeLog |  4 
 gdb/gnu-nat.c | 20 +++-
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index f68a787..8b43cd8 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,9 @@
 2016-12-08  Thomas Schwinge  <tho...@codesourcery.com>
 
+   * gnu-nat.c (gnu_create_inferior): Move nested "trace_me"
+   function...
+   (gnu_ptrace_me): ... here.
+
* i386-gnu-nat.c (i386_gnu_dr_set_control_one)
(i386_gnu_dr_set_addr_one): Explicitly cast "void *".
 
diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index 92b9292..34fd6f1 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -2110,6 +2110,16 @@ cur_inf (void)
 }
 
 static void
+gnu_ptrace_me (void)
+{
+  /* We're in the child; make this process stop as soon as it execs.  */
+  struct inf *inf = cur_inf ();
+  inf_debug (inf, "tracing self");
+  if (ptrace (PTRACE_TRACEME) != 0)
+error (_("ptrace (PTRACE_TRACEME) failed!"));
+}
+
+static void
 gnu_create_inferior (struct target_ops *ops, 
 char *exec_file, char *allargs, char **env,
 int from_tty)
@@ -2117,17 +2127,9 @@ gnu_create_inferior (struct target_ops *ops,
   struct inf *inf = cur_inf ();
   int pid;
 
-  void trace_me (void)
-  {
-/* We're in the child; make this process stop as soon as it execs.  */
-inf_debug (inf, "tracing self");
-if (ptrace (PTRACE_TRACEME) != 0)
-  error (_("ptrace (PTRACE_TRACEME) failed!"));
-  }
-
   inf_debug (inf, "creating inferior");
 
-  pid = fork_inferior (exec_file, allargs, env, trace_me,
+  pid = fork_inferior (exec_file, allargs, env, gnu_ptrace_me,
NULL, NULL, NULL, NULL);
 
   /* Attach to the now stopped child, which is actually a shell...  */
-- 
2.10.2

Fix C++ compilation of the Hurd port

[Thomas Schwinge]

Hi!

I hear, GDB is now a C++ code base?  ;-) (Actually, to the best of my
knowledge, that makes GDB the first C++ project to use low-level
Mach/Hurd interfaces.)

No doubt this will need to be polished some more, but to at least restore
the build, I committed the following five patches to fix C++ compilation
of the Hurd port.


Grüße
 Thomas

Usage of std::string's max_size in the testsuite

[Thomas Schwinge]

Hi!

32-bit x86 GNU/Hurd recently switched from 2 GiB/2 GiB user/kernel
address space to a 3 GiB/1 GiB split.  After that, I see test cases like
libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc
allocate huge amounts of memory.  Looking into this, this is coming from:

[...]
  csize_type csz01, csz02;

  const std::string str01("rodeo beach, marin");
[...]
  csz01 = str01.max_size();
  try {
std::string str04(csz01, 'b'); 
str03 = str04; 
csz02 = str02.size();
try {
  str03.insert(0, str02, 0, 5);
  VERIFY( false );
}
catch(std::length_error& fail) {
  VERIFY( true );
}
catch(...) {
  VERIFY( false );
}
  }
  catch(std::bad_alloc& failure){
VERIFY( true ); 
  }
  catch(std::exception& failure){
VERIFY( false );
  }
[...]

Calling std::string's max_size, csz01, evaluates to 2147483647
(0x7fff, nearly 2 GiB).  (Same on x86 GNU/Linux.)  A new std::string
object, str04, is then constructed with that huge size, and initialized
to "bbb[...]".  Given the availability of 3 GiB user address space, the
kernel will serve this request, but with a lot of swapping.  (The next
huge string then created as a copy, will then exhaust the 3 GiB user
address space.)

I also have to note that GNU/Hurd doesn't have a working RLIMIT
implementation (difficult to implement), so the call to
__gnu_test::set_memory_limits is basically a no-op.  On system where that
is enforced (I tested x86 GNU/Linux), such a huge allocation results in a
std::bad_alloc exception, which is expected and caught.

I have not yet looked in detail into other test cases that also use
max_size similarly.

Assuming such usage of std::string's max_size is considered fine, I
suppose I should mark any such tests to be skipped for GNU/Hurd while
there is no functional RLIMIT implementation?


Grüße
 Thomas

Re: Unreclaimed swap space upon process termination?

[Thomas Schwinge]

Hi!

On Mon, 28 Nov 2016 19:55:20 +0100, Samuel Thibault <samuel.thiba...@gnu.org> 
wrote:
> Thomas Schwinge, on Mon 28 Nov 2016 17:10:26 +0100, wrote:
> > ..., but on the new ("bad") system, the first non-sensical (huge;
> > -2147479552 is 0x80001000) vm_allocate call actually succeeds:
> 
> Yes, the userland address space is now 3G again, so it can now indeed
> allocate that much.

ACK.

> > I have not yet figured out where these vm_allocate calls and/or their
> > huge size parameters are coming from.
> 
> Probably the real source of the issue :)

Will look into that.

Early after a system reboot (second run of the executable), I ran into a
GNU Mach "panic ../vm/vm_page.c:2058: vm_page_evict: vm_page: unable to
recycle any page"; see attached.  As this is new code in GNU Mach (commit
5d1258459ad618481a4f239e8ce020bdecda1d3f "Rework pageout to handle
multiple segments"): anything you'd like me to do/preserve before
rebooting?


Grüße
 Thomas

Re: Unreclaimed swap space upon process termination?

[Thomas Schwinge]

Hi!

On Mon, 28 Nov 2016 16:03:44 +0100, I wrote:
> Updating a Debian GNU/Hurd virtual machine to recent packages after many
> months, and then running the GCC testsuite, I observe the following
> behavior, which should be reproducible with the executable in the
> attached tarball:
> 
> $ vmstat | grep swap\ free
> swap free: 4096M
> $ ./1.exe 
> $ vmstat | grep swap\ free
> swap free: 3288M
> $ ./1.exe 
> $ vmstat | grep swap\ free
> swap free: 2495M
> $ ./1.exe 
> $ vmstat | grep swap\ free
> swap free: 1726M
> $ ./1.exe 
> $ vmstat | grep swap\ free
> swap free:  931M
> $ ./1.exe 
> $ vmstat | grep swap\ free
> swap free:  164M
> $ ./1.exe 
> Bus error
> $ vmstat | grep swap\ free
> swap free:0 
> 
> At this point, the system doesn't recover from this low memory situation.
> 
> For each invocation of the executable, there are three "no more room in
> [...]  (./1.exe([...])" messages on the Mach console.
> 
> The executable is compiled from
> [gcc]/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc
> from commit a050099a416f013bda35832b878d9a57b0cbb231 (gcc-6-branch branch
> point; 2016-04-15), which doesn't look very spectacular -- apart from
> maybe the __gnu_test::set_memory_limits call, which I'll try to figure
> out what it does.

That uses setrlimit for RLIMIT_DATA, RLIMIT_RSS, RLIMIT_VMEM, RLIMIT_AS,
but there is no change with that call removed.

> But nevertheless, unreclaimed swap space upon process
> termination sounds like a bug?
> 
> Unless this a known issue, or somebody can quickly pinpoint the problem,
> I'll try to bisect core system packages, between the version of the
> "good" and "bad" disk images.

Running with rpctrace, I see that on the old ("good") system, at the end
of the process, we got:

[...]
task52(pid2198)->vm_deallocate (16973824 16) = 0 
task52(pid2198)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space 
available) 
task52(pid2198)->vm_allocate (0 -2147348480 1) = 0x3 ((os/kern) no space 
available) 
task52(pid2198)->vm_map (0 2097152 0 1  (null) 0 1 0 7 1) = 0 21405696
task52(pid2198)->vm_deallocate (21405696 614400) = 0 
task52(pid2198)->vm_deallocate (23068672 434176) = 0 
task52(pid2198)->vm_protect (22020096 135168 0 3) = 0 
task52(pid2198)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space 
available) 
  61<--68(pid2198)->proc_mark_exit_request (0 0) = 0 
task52(pid2198)->task_terminate () = 0 
Child 2198 exited with 0

..., but on the new ("bad") system, the first non-sensical (huge;
-2147479552 is 0x80001000) vm_allocate call actually succeeds:

[...]
task154(pid1080)->vm_deallocate (16973824 16) = 0 
task154(pid1080)->vm_allocate (0 -2147479552 1) = 0 268742656
task154(pid1080)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space 
available) 
task154(pid1080)->vm_allocate (0 -2147348480 1) = 0x3 ((os/kern) no space 
available) 
task154(pid1080)->vm_map (0 2097152 0 1  (null) 0 1 0 7 1) = 0 2162
task154(pid1080)->vm_deallocate (2162 364544) = 0 
task154(pid1080)->vm_deallocate (23068672 684032) = 0 
task154(pid1080)->vm_protect (22020096 135168 0 3) = 0 
task154(pid1080)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space 
available) 
task154(pid1080)->vm_deallocate (268742656 -2147479552) = 0 
  163<--170(pid1080)->proc_mark_exit_request (0 0) = 0 
task154(pid1080)->task_terminate () = 0 
Child 1080 exited with 0

I have not yet figured out where these vm_allocate calls and/or their
huge size parameters are coming from.


Grüße
 Thomas

Unreclaimed swap space upon process termination?

[Thomas Schwinge]

Hi!

Updating a Debian GNU/Hurd virtual machine to recent packages after many
months, and then running the GCC testsuite, I observe the following
behavior, which should be reproducible with the executable in the
attached tarball:

$ vmstat | grep swap\ free
swap free: 4096M
$ ./1.exe 
$ vmstat | grep swap\ free
swap free: 3288M
$ ./1.exe 
$ vmstat | grep swap\ free
swap free: 2495M
$ ./1.exe 
$ vmstat | grep swap\ free
swap free: 1726M
$ ./1.exe 
$ vmstat | grep swap\ free
swap free:  931M
$ ./1.exe 
$ vmstat | grep swap\ free
swap free:  164M
$ ./1.exe 
Bus error
$ vmstat | grep swap\ free
swap free:0 

At this point, the system doesn't recover from this low memory situation.

For each invocation of the executable, there are three "no more room in
[...]  (./1.exe([...])" messages on the Mach console.

The executable is compiled from
[gcc]/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc
from commit a050099a416f013bda35832b878d9a57b0cbb231 (gcc-6-branch branch
point; 2016-04-15), which doesn't look very spectacular -- apart from
maybe the __gnu_test::set_memory_limits call, which I'll try to figure
out what it does.  But nevertheless, unreclaimed swap space upon process
termination sounds like a bug?

Unless this a known issue, or somebody can quickly pinpoint the problem,
I'll try to bisect core system packages, between the version of the
"good" and "bad" disk images.


Grüße
 Thomas




1.tar.xz
Description: application/xz

Re: C++ vs. glibc/Hurd/Mach headers

[Thomas Schwinge]

Hi!

On Sun, 27 Nov 2016 17:14:26 +0100, Samuel Thibault <samuel.thiba...@gnu.org> 
wrote:
> Thomas Schwinge, on Sat 26 Nov 2016 19:53:34 +0100, wrote:
> > When changing the GDB source code to use kern_return_t (or int) instead
> > of error_t, I still see hurd.h:__hurd_fail and
> > hurd/signal.h:HURD_MSGPORT_RPC choke on their own error_t usage:
> > 
> > $ echo -e '#include \n#include \n#include 
> > \n#include \nvoid f(){ kern_return_t err = 0; err = 
> > thread_get_state(0,0,0,0); err = HURD_MSGPORT_RPC(0,0,0,0); }' | g++ 
> > -D_GNU_SOURCE -x c++ - -S -o /dev/null -O2
> 
> Don't use 0, but ESUCCESS.

;-) I do know about ESUCCESS (I added it), but the literal 0 (int) here
are to model the fact that Mach API calls have a return type of
kern_return_t (int).  (Thus, I will change GDB's "err" variables from
error_t to kern_return_t.)

> > In file included from /usr/include/errno.h:35:0,
> >  from :1:
> > /usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
> > /usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = EIEIO;
> >  ^
> > /usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = ENOMEM;
> >  ^
> > /usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = EINVAL;

This remains to be fixed; can you please commit your patch?

> The HURD_MSGPORT_RPC seems missing casts between kern_error and error_t
> indeed.

Thanks for changing this code.  Though, the explicit casts are also not
completely ideal, as they now hide other kinds of problems, for example:

$ echo -e '#include \n#include \n#include 
\nvoid f(){ error_t err = HURD_MSGPORT_RPC(,,,); 
}' | gcc -D_GNU_SOURCE -x c - -S -o /dev/null -O2

... in C compilation mode now no longer diagnoses "error: incompatible
types when assigning [...]".  Oh well...  ;-/


Grüße
 Thomas

Re: C++ vs. glibc/Hurd/Mach headers

[Thomas Schwinge]

Hi!

On Sat, 26 Nov 2016 13:36:22 +0100, Samuel Thibault <samuel.thiba...@gnu.org> 
wrote:
> Thomas Schwinge, on Fri 25 Nov 2016 12:46:33 +0100, wrote:
> > Additionally to the issues Samuel pointed
> > out in <https://www.sourceware.org/ml/libc-alpha/2007-08/msg1.html>
> > (still unresolved),
> 
> ?
> 
> I can include hurd/signal.h fine from c++. The second part of my patch
> was applied

Right, hurd/signal.h's hurd_self_sigstate, _hurd_critical_section_lock,
and _hurd_critical_section_unlock have been fixed, but...

> and IIRC we made some changes to error_t.

... I don't see any such changes?

For GDB, the following is expected to work:

$ echo -e '#include \n#include \n#include 
\n#include \nvoid f(){ error_t err = 0; err = 
thread_get_state(0,0,0,0); err = HURD_MSGPORT_RPC(0,0,0,0); }' | g++ 
-D_GNU_SOURCE -x c++ - -S -o /dev/null -O2
In file included from /usr/include/errno.h:35:0,
 from :1:
/usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
/usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EIEIO;
 ^
/usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = ENOMEM;
 ^
/usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EINVAL;
 ^
: In function ‘void f()’:
:5:25: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:50: error: invalid conversion from ‘kern_return_t {aka int}’ to 
‘error_t {aka __error_t_codes}’ [-fpermissive]
In file included from /usr/include/hurd/userlink.h:27:0,
 from /usr/include/hurd/port.h:25,
 from /usr/include/hurd.h:41,
 from :3:
:5:67: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:67: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:67: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]

When changing the GDB source code to use kern_return_t (or int) instead
of error_t, I still see hurd.h:__hurd_fail and
hurd/signal.h:HURD_MSGPORT_RPC choke on their own error_t usage:

$ echo -e '#include \n#include \n#include 
\n#include \nvoid f(){ kern_return_t err = 0; err = 
thread_get_state(0,0,0,0); err = HURD_MSGPORT_RPC(0,0,0,0); }' | g++ 
-D_GNU_SOURCE -x c++ - -S -o /dev/null -O2
In file included from /usr/include/errno.h:35:0,
 from :1:
/usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
/usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EIEIO;
 ^
/usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = ENOMEM;
 ^
/usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EINVAL;
 ^
In file included from /usr/include/hurd/userlink.h:27:0,
 from /usr/include/hurd/port.h:25,
 from /usr/include/hurd.h:41,
 from :3:
: In function ‘void f()’:
:5:73: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:73: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:73: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]


Grüße
 Thomas

Re: Time for another round of releases

[Thomas Schwinge]

Hi!

On Sun, 2 Oct 2016 18:54:05 +0200, Justus Winter  wrote:
> it is October, therefore, it is time for a new set of releases :)

:-)

(I've set a reminder in my calender to trigger every half a year.)  ;-)

..., and again I want to excuse my radio silence...  The good news: we're
getting married.  The bad news: that basically didn't allow to spend any
time on pet projects, in the last weeks/months.  The good news (well, for
us, anyway): we'll soon be leaving for the honeymoon trip.  The bad news:
I didn't manage to squeeze in enough time to prepare the releases.  I
still need to better document/automate what needs to be done (in
particular for updating the web pages).  Will it be OK to move the
release date towards end of November?  (Yay, one more month for getting
stuff finished for inclusion...)  ;'-\


Grüße
 Thomas

Re: [PATCH] drop the deprecated malloc/free hooks in hurd/mach-defpager

[Thomas Schwinge]

Hi!

On Mon, 30 May 2016 23:59:33 +0200, Samuel Thibault  
wrote:
> Justus Winter, on Wed 18 May 2016 13:27:13 +0200, wrote:
> > As Richard said in #hurd, implement mlockall and MCL_FUTURE and just
> > use the default allocator.
> 
> Indeed.

(Conceptually ACK.)


> > or is the removal of that deprecated interface imminent?
> 
> I don't think it's that imminent.

After quite some discussion, it now actually has gotten removed in glibc
2.24: "The deprecated __malloc_initialize_hook variable has been removed
From the API." (from "NEWS for version 2.24").
 "Remove deprecated malloc symbols from
the API".


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: [PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros

[Thomas Schwinge]

Hi!

On Mon, 06 Jun 2016 09:06:35 +0200, l...@gnu.org (Ludovic 
=?utf-8?Q?Court=C3=A8s?=) wrote:
> Samuel Thibault  skribis:
> > Ludovic Courtès, on Sun 05 Jun 2016 21:53:35 +0200, wrote:
> >> Justus Winter  skribis:
> >> > +#define Mach_port_check(NAME)   
> >> > \
> >> > +  void _Mach_port_check_##NAME(char *_unused[] __attribute__ 
> >> > ((unused))) \
> >> > +  { 
> >> > \
> >> > +  if (MACH_PORT_VALID (NAME))   
> >> > \
> >> > +__print_fail_backtrace (#NAME " leaked",
> >> > \
> >> > +__FILE__, __LINE__, "Port leak detector");  
> >> > \
> >> > +  } 
> >> > \
> >> > +  char _Mach_port_check_x_##NAME[0] 
> >> > \
> >> > +  __attribute__ ((unused, cleanup (_Mach_port_check_##NAME)))

That, basically, is encoding the Mach API's semantic information using C
language constructs (specifically here, GCC extensions, which is OK in
our context, of course).  As noted already, this will require us to touch
a lot of the existing code, to have it use this "new" API, basically.

Conceptually, such an improved API seems totally reasonable to me, and I
have thought about such things before.

I don't remember the details right now, but we also toyed with the idea
of a "rich" Mach port class in context of the "Improve Java on Hurd"
Google Summer of Code 2011 project,
.  (Jérémie
Koenig CCed, just in case.)  See "Java bindings for Mach" on that page,
and .  For example, the Java
variant of Justus' Mach_port_check quoted at the beginning of this email,
:

/* Check that the port was deallocated and has no references left at
 * collection time. */
@Override
protected final void finalize() {
if(refCnt > 0) {
System.err.println(String.format(
"MachPort: port name %d was never released", name));
refCnt = 0;
}
if(name != Mach.Port.DEAD) {
System.err.println(String.format(
"MachPort: port %d was never deallocated", name));
deallocate();
}
}

> >> I think writing a GCC plug-in that would automatically add a cleanup
> >> handler to automatic variables of type ‘mach_port_t’ wouldn’t be
> >> unreasonable.
> >
> > I don't enough to be sure, but isn't that the typical work of
> > LocalitySanitizer, precisely?
> 
> Could be!  I’m not familiar with it.

There is no LocalitySanitizer in GCC/LLVM.  ;-)
Re: [PATCH] fix compiler warnings in hurd/exec


2016-05-23

Thread
Thomas Schwinge

Hi!

On Tue, 29 Dec 2015 18:10:27 +0100, Flavio Cruz <flavioc...@gmail.com> wrote:
> exec: Fix compiler warnings.
> 
> * exec/elfcore.c: Cast arguments to vm_address_t.
> * exec/main.c: Use %lu in asprintf.

> --- a/exec/elfcore.c
> +++ b/exec/elfcore.c
> @@ -408,8 +408,8 @@ dump_core (task_t task, file_t file, off_t corelimit,
>   if (err == 0)
> {
>   err = proc_get_arg_locations (proc,
> -   _argv,
> -   _envp);
> +   (vm_address_t *) _argv,
> +   (vm_address_t *) 
> _envp);

Reverted that change, to simplify the code:

commit d213bd8ef04dd947ff5c53a8efeb6cba11621396
Author: Thomas Schwinge <tho...@codesourcery.com>
Date:   Mon May 23 11:30:47 2016 +0200

Revert part of "fix compiler warnings in hurd/exec"

This reverts part of commit 05c3ffac543052c8d0b171a5f77bb977d5316a61.  These
type casts are no longer needed after the commit
e914bfc3d6e5ddf6f8c5e93a4334873a48a24ddf changes.

* exec/elfcore.c: Revert type casts added in commit
05c3ffac543052c8d0b171a5f77bb977d5316a61.
---
 exec/elfcore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git exec/elfcore.c exec/elfcore.c
index 4840217..3e4551e 100644
--- exec/elfcore.c
+++ exec/elfcore.c
@@ -408,8 +408,8 @@ dump_core (task_t task, file_t file, off_t corelimit,
if (err == 0)
  {
err = proc_get_arg_locations (proc,
- (vm_address_t *) _argv,
- (vm_address_t *) 
_envp);
+ _argv,
+ _envp);
mach_port_deallocate (mach_task_self (), proc);
  }
{


> --- a/exec/main.c
> +++ b/exec/main.c
> @@ -145,7 +145,7 @@ trivfs_append_args (struct trivfs_control *fsys,
>  
>if (MACH_PORT_VALID (opt_device_master))
>  {
> -  asprintf (, "--device-master-port=%d", opt_device_master);
> +  asprintf (, "--device-master-port=%lu", opt_device_master);

;-) Strictly speaking, that's not correct: opt_device_master is a
mach_port_t, and there is no requirement for that one to correspond
exactly to an "unsigned long int".  But, I guess, we have a lot of code
making such assumptions, so let's not worry about that for the moment.


Grüße
 Thomas


signature.asc
Description: PGP signature





Re: [PATCH] fix compiler warnings in hurd/procfs


2016-05-23

Thread
Thomas Schwinge

Hi!

On Tue, 29 Dec 2015 23:11:26 +0100, Flavio Cruz <flavioc...@gmail.com> wrote:
> procfs: Fix compiler warnings.
> 
> * include/sys/procfs.h: Change uintptr_t to vm_address_t.
> * procfs/process.c: Fix format strings.
> * procfs/rootdir.c: Add missing casts.

(Note that the  header file does not relate to the procfs
translator.)

> --- a/include/sys/procfs.h
> +++ b/include/sys/procfs.h
> @@ -63,8 +63,8 @@ struct elf_psinfo
>char pr_psargs[ELF_PRARGSZ];   /* Initial part of argument list.  */
>int pr_wstat;  /* Zombie exit status (not really 
> used).  */
>int pr_argc;   /* The argument count at startup.  */
> -  uintptr_t pr_argv; /* Original argument vector address.  */
> -  uintptr_t pr_envp; /* Original environment vector address.  */
> +  vm_address_t pr_argv;  /* Original argument vector address.  */
> +  vm_address_t pr_envp;  /* Original environment vector address. 
>  */
>  };
>  typedef struct elf_psinfo psinfo_t;

Amended as follows.  It may be some kind of
layering/encapsulation/abstraction violation to be including a Mach
header file in , but given that vm_address_t is a Mach
type, it's what we should do.  Maybe we shouldn't be using vm_address_t
here, actually.

commit 305e83c42624c8cf84452d5d0fa7669e2af6f997
Author: Thomas Schwinge <tho...@codesourcery.com>
Date:   Mon May 23 11:23:57 2016 +0200

Make  self-contained again

Commit e914bfc3d6e5ddf6f8c5e93a4334873a48a24ddf made 
Autoconf/configure tests change as follows:

checking sys/procfs.h usability... [-yes-]{+no+}
checking sys/procfs.h presence... yes
{+configure: WARNING: sys/procfs.h: present but cannot be compiled+}
{+configure: WARNING: sys/procfs.h: check for missing prerequisite 
headers?+}
{+configure: WARNING: sys/procfs.h: see the Autoconf documentation+}
{+configure: WARNING: sys/procfs.h: section "Present But Cannot Be 
Compiled"+}
{+configure: WARNING: sys/procfs.h: proceeding with the compiler's 
result+}
checking for sys/procfs.h...[-yes-]{+no+}
[-checking for prstatus_t in sys/procfs.h... no-]
[-checking for prstatus32_t in sys/procfs.h... no-]
[-checking for prstatus_t.pr_who in sys/procfs.h... no-]
[-checking for prstatus32_t.pr_who in sys/procfs.h... no-]
[-checking for pstatus_t in sys/procfs.h... yes-]
[-checking for pxstatus_t in sys/procfs.h... no-]
[-checking for pstatus32_t in sys/procfs.h... no-]
[-checking for prpsinfo_t in sys/procfs.h... no-]
[-checking for prpsinfo_t.pr_pid in sys/procfs.h... no-]
[-checking for prpsinfo32_t in sys/procfs.h... no-]
[-checking for prpsinfo32_t.pr_pid in sys/procfs.h... no-]
[-checking for psinfo_t in sys/procfs.h... yes-]
[-checking for psinfo_t.pr_pid in sys/procfs.h... yes-]
[-checking for psinfo32_t in sys/procfs.h... no-]
[-checking for psinfo32_t.pr_pid in sys/procfs.h... no-]
[-checking for lwpstatus_t in sys/procfs.h... yes-]
[-checking for lwpxstatus_t in sys/procfs.h... no-]
[-checking for lwpstatus_t.pr_context in sys/procfs.h... no-]
[-checking for lwpstatus_t.pr_reg in sys/procfs.h... yes-]
[-checking for lwpstatus_t.pr_fpreg in sys/procfs.h... yes-]
[-checking for win32_pstatus_t in sys/procfs.h... no-]

That is because of:

$ echo '#include ' | gcc -x c - -o /dev/null -S
In file included from :1:0:
/usr/include/sys/procfs.h:66:3: error: unknown type name ‘vm_address_t’
   vm_address_t pr_argv;  /* Original argument vector address.  */
   ^
/usr/include/sys/procfs.h:67:3: error: unknown type name ‘vm_address_t’
   vm_address_t pr_envp;  /* Original environment vector address.  */
   ^

* include/sys/procfs.h: Include  to make file 
self-contained
again.
---
 include/sys/procfs.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git include/sys/procfs.h include/sys/procfs.h
index 09d2030..4acc346 100644
--- include/sys/procfs.h
+++ include/sys/procfs.h
@@ -1,5 +1,5 @@
 /*  -- data structures describing ELF core file formats
-   Copyright (C) 2002 Free Software Foundation, Inc.
+   Copyright (C) 2002, 2015, 2016 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 


Grüße
 Thomas


signature.asc
Description: PGP signature





GNU Hurd 0.8, GNU Mach 1.7, GNU MIG 1.7 released


2016-05-18

Thread
Thomas Schwinge

Hi!

Please see
.

Text-only version:

| GNU Hurd 0.8, GNU Mach 1.7, GNU MIG 1.7 released.
| 
| We're pleased to announce new releases!
| 
| GNU Hurd 0.8, NEWS:
| 
| Version 0.8 (2016-05-18)
| 
| 
| The netfs library is using the lockless reference-counting primitives
| for both peropen and node objects now, and the global reference
| counting lock has been removed.
| 
| 
| The integer hashing library gained a new interface to use non-integer
| keys.  It is now used in libdiskfs' and nfs' node cache, and the ftpfs
| translator.
| 
| 
| Several bugs in our native fakeroot tool have been fixed improving
| stability and correctness of the translation.
| 
| 
| The devnode translator and the hurd-slab library have been merged into 
this
| repository.
| 
| 
| The code has been cleaned up, and we fixed numerous bugs, most notably
| a crash in pfinet, a locking bug in libdiskfs, and an out-of-bounds
| access in ext2fs' block cache.
| 
| Release tarballs may be downloaded from ftp://ftp.gnu.org/gnu/hurd/, 
http://ftp.gnu.org/gnu/hurd/, or checked out of Git, 
http://git.savannah.gnu.org/cgit/hurd/hurd.git. SHA1 checksums:
| 
| 38585aed93645704477d91d01136e1ae750a5ecb  hurd-0.8.tar.bz2
| 531d5035427830e87828a79bf6794531250784d0  hurd-0.8.tar.bz2.sig
| 6383479f30933d760c6d981fdd37df27adb5f0bb  hurd-0.8.tar.gz
| 63f58d392cb6e0c0ebd71e725938a13a5cab2392  hurd-0.8.tar.gz.sig
| 
| The GNU Hurd is the GNU project's replacement for the Unix kernel. It is 
a collection of servers that run on the Mach microkernel to implement file 
systems, network protocols, file access control, and other features that are 
implemented by the Unix kernel or similar kernels (such as Linux). More 
detailed: documentation, what is the GNU Hurd.
| 
| GNU Mach 1.7, NEWS:
| 
| Version 1.7 (2016-05-18)
| 
| 
| The code has been updated to work with newer versions of GCC, and 
numerous bugs
| have been fixed throughout the code, including a pageout deadlock.  The 
code
| uses integer types from  now instead of the old Mach types.
| 
| 
| The VM cache policy change has been merged.  The kernel now caches
| unreferenced VM objects unconditionally instead of using a fixed
| limit.
| 
| 
| The physical page allocator of the X15 kernel has been integrated, and
| is now used directly by the slab allocator.  This increases the kernel
| heap addressing important scalability issues.
| 
| 
| The gsync synchronization mechanism was added, similar to the Linux 
kernel's
| futexes, to allow efficient and powerful userland synchronization.
| 
| 
| Support for profiling kernel code from userland through sampling was 
added.
| 
| Release tarballs may be downloaded from ftp://ftp.gnu.org/gnu/gnumach/, 
http://ftp.gnu.org/gnu/gnumach/, or checked out of Git, 
http://git.savannah.gnu.org/cgit/hurd/gnumach.git. SHA1 checksums:
| 
| 4438c7c10f8eef019ada45b749c0796d620d08de  gnumach-1.7.tar.bz2
| 6cdf299118066e3280dcc68f75477659fc783f7d  gnumach-1.7.tar.bz2.sig
| 5474b2cdc01cb002149db08d745fdab741470c65  gnumach-1.7.tar.gz
| 018aa0551e87c4b5eeb900934491811f46ab8b78  gnumach-1.7.tar.gz.sig
| 
| GNU Mach is the GNU distribution of the Mach microkernel, upon which a 
GNU Hurd system is based. The microkernel provides an Inter Process 
Communication (IPC) mechanism that the Hurd uses to define interfaces for 
implementing in a distributed multi-server fashion the services a traditional 
operating system kernel provides. More detailed: documentation.
| 
| GNU MIG 1.7, NEWS:
| 
| Version 1.7 (2016-05-18)
| 
| 
| * MIG now has a test suite.  It includes a set of valid and invalid
|   definition files that MIG will try to process.  For valid
|   definitions, GCC will compile the stubs to check if valid C code was
|   generated.
| 
| 
| * The generated code uses integer types from  now instead of
|   the old Mach types.
| 
| 
| * Code that was hard-coding the word size has been identified and
|   fixed.
| 
| 
| * Support for the obsolete kinds of RPC routines 'functions',
|   'procedures', and 'simple procedures' has been removed.
| 
| 
| * MIG now emits code that casts objects translated from capabilities
|   to the correct C type.
| 
| Release tarballs may be downloaded from ftp://ftp.gnu.org/gnu/mig/, 
http://ftp.gnu.org/gnu/mig/, or checked out of Git, 
http://git.savannah.gnu.org/cgit/hurd/mig.git. SHA1 checksums:
| 
| 25d87f0271678d044a8af1f45492a96bee32e486  mig-1.7.tar.bz2
| 481dce92b8eb718231bf9d409c0e0c9337dc1f90  mig-1.7.tar.bz2.sig
| f1bd05d1b353653f49dbbb44a4624e65c7be0a2e  mig-1.7.tar.gz
| 59f71517cd1be26635a27da423bcf75e2399a42e  mig-1.7.tar.gz.sig
| 
| GNU MIG is the GNU distribution of the Mach 3.0 Interface Generator 
(MIG). This tool translates Remote 



Re: [PATCH] drop the deprecated malloc/free hooks in	hurd/mach-defpager


2016-05-16

Thread
Thomas Schwinge

Hi!

On Tue, 29 Dec 2015 23:09:54 +0100, Flavio Cruz  wrote:
> mach-defpager: Drop the deprecated malloc/free hooks.

(After approval by Samuel, this became commit
8c49801c8f7e3f800cabedf8fca8ccec3cf35a22.)

> * mach-defpager/kalloc.c: Define malloc and free directly since those are weak
> symbols.

The idea here is to just change the mechanism (override glibc's weak
symbols instead of using glibc's deprecated malloc hooks), while not
changing any semantics, right?

From a quick look, I have some doubts about this generally (so, not only
related to your change).

> --- a/mach-defpager/kalloc.c
> +++ b/mach-defpager/kalloc.c

> -static void *
> -malloc_hook (size_t size, const void *caller)
> +void *
> +malloc (size_t size)
>  {
>return (void *) kalloc ((vm_size_t) size);
>  }
>  
> -static void
> -free_hook (void *ptr, const void *caller)
> +void
> +free (void *ptr)
>  {
>/* Just ignore harmless attempts at cleanliness.  */
>/* panic("free not implemented"); */

So, here we now only provide the malloc and free symbols.  What happens
if, for example, calloc, realloc, posix_memalign et al. are called?

For example, looking at [glibc]/malloc/malloc.c:__libc_calloc (weak alias
for calloc).  Before your change, it called mach-defpager's malloc_hook,
and then zeroed that region.  After your change, it is implemented using
the real glibc calloc -- which actually does change the semantics in an
unintended way?

Backing up one step: what is actually being done here in mach-defpager?
Again from just a quick look, is the idea to use wired memory for all of
mach-defpager's process memory?

So, for example, if now some mach-defpager code calls calloc, it will now
get non-wired "glibc" memory instead of wired "kalloc" memory.  The
problem here is not mach-defpager's own code (which we can easily
verify/control), but the problems is the libraries it links against,
which currently are: libihash, libpthread, glibc itself, and any
dependencies these may have.  Can we be sure these are not internally
using calloc, for example?

Now, this is not a new problem that you introduced ;-) -- previously we
also didn't provide malloc's memalign and realloc hooks, and realloc is
used quite commonly, I suppose?

If my theories are correct, do we need to use a different mechanism to
get the whole mach-defpager process into wired memory?


Grüße
 Thomas


signature.asc
Description: PGP signature





Complete changes to use -L instead of -Wl,	-rpath-link (was: [SCM] Hurd branch, master,	updated. v0.7-16-gc9c29eb)


2016-05-16

Thread
Thomas Schwinge

Hi Samuel!

On Sun, 29 Nov 2015 15:49:00 +, Samuel Thibault 
<samuel.thiba...@ens-lyon.org> wrote:
> commit c9c29eb890527fe68900e4a0af7c2df9a9fa5b40
> Author: Samuel Thibault <samuel.thiba...@ens-lyon.org>
> Date:   Sun Nov 29 16:47:06 2015 +0100
> 
> Use -L instead of -Wl,-rpath-link
> 
> The latter does not work for libpthread.a which passes -lihash, which 
> would
> find the installed libihash.a instead of the just-compiled one.
> 
> * Makeconf (rpath): Remove, replaced by...
> (lpath): ... new variable.
> (link-executable, $(libname).so.$(hurd-version)): Use $(lpath) instead of
> $(rpath).

Please verify these additional changes -- you probably just missed these
by accident?

commit 34071b357d821cc6285ef85d600dfa842252949c
Author: Thomas Schwinge <tho...@codesourcery.com>
Date:   Mon May 16 16:49:30 2016 +0200

Complete changes to use -L instead of -Wl,-rpath-link

Changes missing from commit c9c29eb890527fe68900e4a0af7c2df9a9fa5b40.

* console-client/Makefile (%.so.$(hurd-version)): Use $(lpath) instead of
$(rpath)
* libstore/Makefile (libstore_%.so.$(hurd-version)): Likewise.
---
 console-client/Makefile | 5 +++--
 libstore/Makefile   | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git console-client/Makefile console-client/Makefile
index 1784d7c..024a053 100644
--- console-client/Makefile
+++ console-client/Makefile
@@ -1,6 +1,7 @@
 #
 #   Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2004,
-#   2005, 2008, 2010 Free Software Foundation, Inc.
+#   2005, 2008, 2010, 2011, 2012, 2013, 2014, 2015, 2016 Free Software
+#   Foundation, Inc.
 #
 #   This program is free software; you can redistribute it and/or
 #   modify it under the terms of the GNU General Public License as
@@ -91,7 +92,7 @@ $(module-dir)/%: %
 # You can use this rule to make a dynamically-loadable version of any
 # of the modules.
 %.so.$(hurd-version): 
-   $(CC) -shared -Wl,-soname=$@ -o $@ $(rpath) \
+   $(CC) -shared -Wl,-soname=$@ -o $@ $(lpath) \
$(CFLAGS) $($*-CFLAGS) $(LDFLAGS) \
'-Wl,-(' $($*-LDLIBS) '-Wl,-)' $^
 
diff --git libstore/Makefile libstore/Makefile
index 28f5660..3ba0017 100644
--- libstore/Makefile
+++ libstore/Makefile
@@ -1,6 +1,7 @@
 # Makefile for libstore
 #
-#   Copyright (C) 1995,96,97,2001,02 Free Software Foundation, Inc.
+#   Copyright (C) 1995, 1996, 1997, 1999, 2001, 2002, 2010, 2012, 2013, 2014,
+#   2016 Free Software Foundation, Inc.
 #   Written by Miles Bader <mi...@gnu.org>
 #
 #   This file is part of the GNU Hurd.
@@ -73,7 +74,7 @@ libstore_bunzip2.so.$(hurd-version): $(BUNZIP2_OBJS:.o=_pic.o)
 # just include all the standard store types in libstore.so itself.
 libstore_%.so.$(hurd-version): %_pic.o libstore.so
$(CC) -shared -Wl,-soname=$@ -o $@ \
- $(rpath) $(CFLAGS) $(LDFLAGS) $(libstore_$*.so-LDFLAGS) $^
+ $(lpath) $(CFLAGS) $(LDFLAGS) $(libstore_$*.so-LDFLAGS) $^
 
 # Each libstore_TYPE.a is in fact an object file script so that `-lstore_TYPE'
 # just has the same effect as `-u store_TYPE_class'.


Grüße
 Thomas


signature.asc
Description: PGP signature





Re: ext2fs crash


2016-05-13

Thread
Thomas Schwinge

Hi!

On Mon, 09 May 2016 16:11:52 +0200, Justus Winter 
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting Thomas Schwinge (2016-04-27 22:53:33)
> > [...]
> > I suppose we want to fix (or, at least understand) that problem before
> > making the releases?
> 
> No.  Let's take what we have and release it.  Even though some people
> are having trouble with ext2fs, for most people it is working really
> well (e.g. the build daemons).

So, the ext2fs issues (bogus port deallocations, crash) are something to
look into (later, I agree), and the GCC/libstdc++ testsuite issue in fact
is not related to "our" packages (Hurd et al.):

Current status:

$ make check-target-libstdc++-v3 
RUNTESTFLAGS=conformance.exp=27_io/basic_filebuf/showmanyc/char/9533-1.cc

i686-unknown-gnu0.7/libstdc++-v3/testsuite/libstdc++.log:

[...]
PASS: 27_io/basic_filebuf/showmanyc/char/9533-1.cc (test for excess errors)
Setting LD_LIBRARY_PATH to [...]
Execution timeout is: 300
spawn [open ...]
WARNING: program timed out.
[Hangs here.]
[C-c]
got a INT signal, interrupted by user 

=== libstdc++ Summary ===

# of expected passes1
runtest completed at [...]

Downgrading dejagnu from 1.6-1 back to the previous 1.5.3-2 resolves the
problem:

[...]
PASS: 27_io/basic_filebuf/showmanyc/char/9533-1.cc (test for excess errors)
Setting LD_LIBRARY_PATH to [...]
spawn [open ...]
WARNING: program timed out.
FAIL: 27_io/basic_filebuf/showmanyc/char/9533-1.cc execution test
testcase [...]/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
completed in 632 seconds

=== libstdc++ Summary ===

# of expected passes1
# of unexpected failures1
runtest completed at [...]

(The timeout and FAIL are currently to be expected.)  Phew.  So, I'll
(later) try to figure out what's going on there...


> Do you need help with the announcements?

Thanks for having prepared the NEWS files updates already.  I'm working
on the releases; these won't go out today, but tomorrow, I suppose.
"Timeout, server git.savannah.gnu.org not responding."  ;-)


Grüße
 Thomas


signature.asc
Description: PGP signature





ext2fs crash


2016-04-27

Thread
Thomas Schwinge

Hi!

Before preparing the next set of releases, I wanted to sort-of
sanity-check what we currently got (at least in terms of Debian
packages), so yesterday dist-upgraded my Debian GNU/Hurd system to the
latest packages, and started a GCC bootstrap build and testsuite run.
That one didn't complete successfully...

I can confirm that the

issue appears to be fixed -- yay, thanks!

The GCC testsuite got stuck on libstdc++'s
27_io/basic_filebuf/showmanyc/char/9533-1.cc.  That one compiles fine but
already before has been known to FAIL its execution testing with
"WARNING: program timed out" (probably the sort-of known frame unwinding
"deficiencies"?), but now, the whole testing harness seems to have gotten
stuck.  Manually SIGKILLing the 9533-1 process, testing continued, but
then got stuck on libstdc++'s 30_threads/async/forced_unwind.cc, which
also before has been known to FAIL its execution testing with "WARNING:
program timed out", but without making the testing harness get stuck.
Poking on forced_unwind.exe for a bit with GDB, I found the "standard"
two-threads process stuck in some pthread_cond_wait (lost the backtrace).
Eventually, ext2fs seems to have crashed ("resource lost" messages).
After rebooting, and compiling the 9533-1.cc test case with the system
compiler:

$ g++-5 -Ilibstdc++-v3/testsuite/util 
libstdc++-v3/testsuite/27_io/basic_filebuf/showmanyc/char/9533-1.cc -g

... I got the following backtrace, which unfortunately is not helpful at
all:

$ gdb -q ./a.out
Reading symbols from ./a.out...done.
(gdb) r
Starting program: [...]/a.out
[hangs]
^C[New Thread 1138.5]

Program received signal SIGINT, Interrupt.
0x01253a55 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
132 intr-msg.c: No such file or directory.
(gdb) info threads
  Id   Target Id Frame
  5Thread 1138.5 0x012374fc in mach_msg_trap () at 
/build/glibc-2.22/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
* 4Thread 1138.4 0x01253a55 in _hurd_intr_rpc_msg_in_trap () at 
intr-msg.c:132
  3bogus thread id 3 Can't fetch registers from thread bogus thread id 
3: No such thread
(gdb) thread apply all bt

Thread 5 (Thread 1138.5):
#0  0x012374fc in mach_msg_trap () at 
/build/glibc-2.22/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
#1  0x01237c96 in __mach_msg (msg=0x145cf60, option=2, send_size=0, 
rcv_size=4096, rcv_name=11, timeout=0, notify=0) at msg.c:110
#2  0x0123825b in __mach_msg_server_timeout (demux=0x1248330 
, max_size=4096, rcv_name=11, option=0, timeout=0) at 
msgserver.c:100
#3  0x01238384 in __mach_msg_server (demux=0x1248330 , 
max_size=4096, rcv_name=11) at msgserver.c:195
#4  0x0124841e in _hurd_msgport_receive () at msgportdemux.c:67
#5  0x66688b92 in ?? ()

Thread 4 (Thread 1138.4):
#0  0x01253a55 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
#1  0x0036 in ?? ()

I then ran that once more, in hope for a better backtrace, and in
parallel copied the existing GCC test log files off of the Hurd system;
shortly after that (?), ext2fs crashed with the following on the console
(manually transcribed):

/hurd/crash: /hurd/ext2fs /dev/hd2(423) crashed, signal {no:11, code:2, 
error:2}, exception {1, code:2, subcode:92671996}, PCs: {0x112a4fc, 0x112a4fc, 
0x112a4fc, 0x112a4fc, 0x112a4fc, 0x112a4fc, 0x112a4fc, 0x132868c, 0x112a4fc}, 
killing task.

I suppose we want to fix (or, at least understand) that problem before
making the releases?

I don't know if that's the actual problem, but building the attached
sources with:

$ g++-5 -I. 9533-1.cc -g

..., and the running that executablerepeatedly, I see stuff like:

$ while :; do echo -n .; ./a.out & p=$!; kill $p; done
[...]
.[1885] 5605
[1884]   Terminated  ./a.out
.[1886] 5609
[1885]   Terminated  ./a.out
*** Error in `./a.out': double free or corruption (!prev): 0x0804e4a8 ***
.[1887] 5613
[1886]   Terminated  ./a.out
.[1888] 5617
[1887]   Terminated  ./a.out

..., and on the console messages about "task /hurd/ext2fs(2090)
deallocating a bogus port [...]", repeating every once in a while.

Have to stop here, unfortunately.


Grüße
 Thomas


// { dg-require-fork "" }
// { dg-require-mkfifo "" }

// Copyright (C) 2003-2016 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.  



Re: Bug#753791: Java failures in packs on hurd-i386... [Bug#753791:	simgrid: FTBFS on hurd-i386]


2016-03-30

Thread
Thomas Schwinge

Hi!

On Sun, 31 Aug 2014 18:41:41 +0200, Samuel Thibault  
wrote:
> Matthias Klose, le Sun 31 Aug 2014 18:39:21 +0200, a écrit :
> > Am 31.08.2014 um 03:10 schrieb Samuel Thibault:
> > > guess that will just fix all our issues...  I'll then commit that and
> > > push upstream.
> > 
> > is this necessary for the libgc package too? (and all embedded libgc copies 
> > in
> > other packages)?
> 
> They would suffer from the same issue, yes.

I just filed .


Grüße
 Thomas


signature.asc
Description: PGP signature





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


2016-03-29

Thread
Thomas Schwinge

Hi!

On Wed, 24 Feb 2016 23:46:36 +0100, I wrote:
> On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault <samuel.thiba...@gnu.org> 
> 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:

commit 9b2eb5d3268cf674f9a6964479f20428e0b43500
Author: tschwinge <tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Tue Mar 29 21:17:53 2016 +

[Hurd] Specs maintenance

gcc/
* config/gnu.h (CPP_SPEC, LIB_SPEC): Don't override.
* config/i386/gnu.h (STARTFILE_SPEC): Use gcrt1.o instead of
gcrt0.o if linking dynamically.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234535 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog | 6 ++
 gcc/config/gnu.h  | 8 
 gcc/config/i386/gnu.h | 4 ++--
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 866531f..37e2504 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-03-29  Thomas Schwinge  <tho...@codesourcery.com>
+
+   * config/gnu.h (CPP_SPEC, LIB_SPEC): Don't override.
+   * config/i386/gnu.h (STARTFILE_SPEC): Use gcrt1.o instead of
+   gcrt0.o if linking dynamically.
+
 2016-03-10  Jan Hubicka  <hubi...@ucw.cz>
 
PR ipa/70283
diff --git gcc/config/gnu.h gcc/config/gnu.h
index 1d98ec8..1dbecda 100644
--- gcc/config/gnu.h
+++ gcc/config/gnu.h
@@ -19,14 +19,6 @@ You should have received a copy of the GNU General Public 
License
 along with GCC.  If not, see <http://www.gnu.org/licenses/>.
 */
 
-/* Provide GCC options for standard feature-test macros.  */
-#undef CPP_SPEC
-#define CPP_SPEC "%{posix:-D_POSIX_SOURCE}"
-
-/* Default C library spec.  */
-#undef LIB_SPEC
-#define LIB_SPEC "%{pthread:-lpthread} %{pg|p|profile:-lc_p;:-lc}"
-
 #undef GNU_USER_TARGET_OS_CPP_BUILTINS
 #define GNU_USER_TARGET_OS_CPP_BUILTINS()  \
 do {   \
diff --git gcc/config/i386/gnu.h gcc/config/i386/gnu.h
index c726d31..9d2f94f 100644
--- gcc/config/i386/gnu.h
+++ gcc/config/i386/gnu.h
@@ -27,11 +27,11 @@ 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: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}}
 \
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|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}"
 #endif
 


Grüße
 Thomas


signature.asc
Description: PGP signature





Re: [PATCH,boehm-gc] Use mmap instead of brk on kfreebsd & hurd too


2016-03-29

Thread
Thomas Schwinge

Hi!

On Sun, 31 Aug 2014 17:20:04 +0200, Samuel Thibault  
wrote:
> Please use mmap instead of brk on kfreebsd and hurd too.
> Also, using anonymous memory is faster on the Hurd.

> [patch]

Thanks; finally committed in r234534:

commit 04a4d1ce0425912054b6f8db5bc15029bf87e055
Author: tschwinge 
Date:   Tue Mar 29 21:05:07 2016 +

[Hurd, kFreeBSD] boehm-gc: Use mmap instead of brk

boehm-gc/
* configure.host: Set gc_use_mmap on *-kfreebsd-gnu* and *-gnu*.
* include/private/gcconfig.h [HURD && USE_MMAP]: Define
USE_MMAP_ANON.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234534 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 boehm-gc/ChangeLog  | 6 ++
 boehm-gc/configure.host | 2 +-
 boehm-gc/include/private/gcconfig.h | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git boehm-gc/ChangeLog boehm-gc/ChangeLog
index c41734a..6896c67 100644
--- boehm-gc/ChangeLog
+++ boehm-gc/ChangeLog
@@ -1,3 +1,9 @@
+2016-03-29  Samuel Thibault  
+
+   * configure.host: Set gc_use_mmap on *-kfreebsd-gnu* and *-gnu*.
+   * include/private/gcconfig.h [HURD && USE_MMAP]: Define
+   USE_MMAP_ANON.
+
 2016-03-16  Andreas Schwab  
 
* include/private/gcconfig.h [AARCH64] (ALIGNMENT, CPP_WORDSZ):
diff --git boehm-gc/configure.host boehm-gc/configure.host
index 97f4dac..229a038 100644
--- boehm-gc/configure.host
+++ boehm-gc/configure.host
@@ -41,7 +41,7 @@ else
 fi
 
 case "${host}" in
-  *-linux*)
+  *-linux*|*-kfreebsd-gnu*|*-gnu*)
 gc_use_mmap=yes
 ;;
 esac
diff --git boehm-gc/include/private/gcconfig.h 
boehm-gc/include/private/gcconfig.h
index aa81f15..44b9d7d 100644
--- boehm-gc/include/private/gcconfig.h
+++ boehm-gc/include/private/gcconfig.h
@@ -2137,7 +2137,7 @@
 #   endif
 # endif
 
-#if defined(LINUX) && defined(USE_MMAP)
+#if (defined(LINUX) || defined(HURD)) && defined(USE_MMAP)
 /* The kernel may do a somewhat better job merging mappings etc.   */
 /* with anonymous mappings.
*/
 #   define USE_MMAP_ANON


Grüße
 Thomas


signature.asc
Description: PGP signature





Re: [PATCH] Use uint32_t instead of unsigned32_t.


2016-03-20

Thread
Thomas Schwinge

Hi!

On Sun, 20 Mar 2016 00:30:30 +0100, Samuel Thibault  
wrote:
> Flávio Cruz, on Sat 19 Mar 2016 14:20:34 +0100, wrote:
> > We already include mach/std_types.h in the stubs which provides uint32_t.

> Should gnumach perhaps just rely on stdint.h?

Relying on existing, standard header files generally makes sense.  As I
understand it,  is part of the freestanding C implementation
(see , for example).  (I'm aware that we
currently don't built GNU Mach with -ffreestanding; but we should -- at
least conceptually.)


Grüße
 Thomas


signature.asc
Description: PGP signature





sysdeps/mach/hurd/profil.c (was: [PATCH] hurd: align -p and -pg	behavior on Linux)


2016-02-25

Thread
Thomas Schwinge

Hi!

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...)

Now looking at glibc code of a similar vintage.  ;-)

> In my understanding, the Hurd needs crt0.o for static linking, and crt1.o
> for dynamic linking.  Likewise, for -pg or -p, I would assume that we
> still need gcrt0.o for static linking, and gcrt1.o for dynamic linking.

> I'm now testing the following patch: [...]
> ..., which results in the following spec changes:
> [...]
>  *startfile:
> -%{!shared: 
> %{pg|p|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}
> +%{!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}

According to the GCC testsuite, that seems alright: a bunch of
UNSUPPORTED -> PASS progressions in gcc.sum.  (But I have not yet done
any manual testing with gprof and such.)

I also see a handful of executions FAILs, the first of which I've now
looked into.  I'll work on getting a glibc build going, to patch this up,
but posting my analysis already, in case anyone has any comments.
(Roland?)

$ gcc/xgcc -Bgcc/ ../trunk/gcc/testsuite/gcc.dg/20021014-1.c -O2 -p -o 
./20021014-1.exe
$ gdb -q 20021014-1.exe 
Reading symbols from 20021014-1.exe...done.
(gdb) r
Starting program: [...]/20021014-1.exe 
[New Thread 15527.5]
[New Thread 15527.6]

Program received signal SIGFPE, Arithmetic exception.
0x01173155 in fetch_samples () at ../sysdeps/mach/hurd/profil.c:164
164 ../sysdeps/mach/hurd/profil.c: No such file or directory.
(gdb) bt
#0  0x01173155 in fetch_samples () at ../sysdeps/mach/hurd/profil.c:164
#1  0x01173365 in __profil (sample_buffer=0x0, size=0, offset=0, scale=0) 
at ../sysdeps/mach/hurd/profil.c:126
#2  0x0117292d in __moncontrol (mode=0) at gmon.c:93
#3  0x01172b56 in _mcleanup () at gmon.c:425
#4  0x0109c617 in __run_exit_handlers (status=0, listp=0x122055c 
<__exit_funcs>, run_list_atexit=true) at exit.c:82
#5  0x0109c661 in exit (status=0) at exit.c:104
#6  0x080484cd in main () at ../trunk/gcc/testsuite/gcc.dg/20021014-1.c:24

That is the "special_profil_failure" in
../sysdeps/mach/hurd/profil.c:fetch_samples.

(gdb) print special_profil_failure 
$1 = EMACH_RCV_INVALID_NAME

[glibc]/sysdeps/mach/hurd/bits/errno.h:

[...]
/* Errors from .  */
[...]
EMACH_RCV_INVALID_NAME  = 0x10004002,
[...]

[gnumach]/include/mach/message.h:

[...]
#define MACH_RCV_INVALID_NAME   0x10004002
/* Bogus name for receive port/port-set. */
[...]

We do have a profile thread created:

(gdb) print profile_thread 
$2 = 63
(gdb) info threads
  Id   Target Id Frame 
  6Thread 15527.6profile_waiter () at 
../sysdeps/mach/hurd/profil.c:183
  5Thread 15527.50x0105c92c in mach_msg_trap () at 
/build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
* 4Thread 15527.40x01173155 in fetch_samples () at 
../sysdeps/mach/hurd/profil.c:164
  3bogus thread id 3 Can't fetch registers from thread bogus thread id 
3: No such thread

..., but it's not yet been scheduled for execution:

(gdb) thread 6
[Switching to thread 6 (Thread 15527.6)]
#0  profile_waiter () at ../sysdeps/mach/hurd/profil.c:183
183 in ../sysdeps/mach/hurd/profil.c
(gdb) bt
#0  profile_waiter () at ../sysdeps/mach/hurd/profil.c:183
Backtrace stopped: Cannot access memory at address 0x2285000
(gdb) disassemble 
Dump of assembler code for function profile_waiter:
=> 0x011731b0 <+0>: push   %ebp
   0x011731b1 <+1>: push   %edi
   0x011731b2 <+2>: push   %esi
   0x011731b3 <+3>: push   %ebx
   0x011731b4 <+4>: mov$0x1,%esi
   0x011731b9 <+9>: call   0x11a06a9 <__x86.get_pc_thunk.bx>
[...]

That is, the profile thread has not actually began to execute, when the
main thread already tears down the process.  During that, the main thread
talks to profil_reply_port -- but that one is (to be) set up by the
profile thread, which has not yet happened:

(gdb) print profil_reply_port
$3 = 0

The scenario is not surprising: [gcc]/gcc/testsuite/gcc.dg/20021014-1.c
is just a few lines of code.

Should we move the initialization of profil_reply_port elsewhere, or be
prepared for profil_reply_port to be MACH_PORT_NULL in
sysdeps/mach/hurd/profil.c:fetch_samples (by returning early?), or not
call fetch_samples from sysdeps/mach/hurd/profil.c:__profil if
profil_reply_port is MACH_PORT_NULL, or 



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


2016-02-24

Thread
Thomas Schwinge

Hi!

Sorry for the late answer...

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.


>   * gcc/config/gnu.h (LIB_SPEC) [-p|-pg]: Link with -lc instead of -lc_p.

> --- 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}"

I guess, we can just drop that custom LIB_SPEC altogether, and will then
use the default (which is also used for x86 GNU/Linux):

gcc/config/gnu-user.h:#define GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC \
gcc/config/gnu-user.h-  "%{shared:-lc} \
gcc/config/gnu-user.h-   %{!shared:%{mieee-fp:-lieee} 
%{profile:-lc_p}%{!profile:-lc}}"
gcc/config/gnu-user.h-
gcc/config/gnu-user.h:#define GNU_USER_TARGET_LIB_SPEC \
gcc/config/gnu-user.h-  "%{pthread:-lpthread} " \
gcc/config/gnu-user.h:  GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC
gcc/config/gnu-user.h-
gcc/config/gnu-user.h:#undef  LIB_SPEC
gcc/config/gnu-user.h:#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC

I have not tested the -mieee-fp thingy, but I don't expect any issues
there; looke like this on both x86 GNU/Linux and GNU/Hurd:

$ nm /usr/lib/i386-*gnu/libieee.a
 D _LIB_VERSION


That said, I think we can also drop our custom CPP_SPEC:

gcc/config/gnu.h:#define CPP_SPEC "%{posix:-D_POSIX_SOURCE}"

..., and instead go with the default:

gcc/config/i386/gnu-user-common.h:#define CPP_SPEC 
"%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"

(It doesn't matter for GNU/Hurd which is x86-only, but I don't know why
CPP_SPEC is defined in gcc/config/i386/gnu-user-common.h -- and repeated
in a number of other GNU-user and */linux.h files -- instead of putting
it into the generic gcc/config/gnu-user.h?)

I guess getting -D_REENTRANT for -pthread won't do us any harm?


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

> --- 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

I think I understand what you're trying to do (avoid gcrt0.o being used
for -pg or -p, and instead use gcrt1.o), but I'm not sure this is
completely correct.  Which of the several configurations, that is, flags
and their combinations, did you actually test?

In my understanding, the Hurd needs crt0.o for static linking, and crt1.o
for dynamic linking.  Likewise, for -pg or -p, I would assume that we
still need gcrt0.o for static linking, and gcrt1.o for dynamic linking.
Instead you're now suggesting to always use gcrt1.o for -pg or -p, and
gcrt0.o for -profile.


I'm now testing the following patch:

--- gcc/config/gnu.h
+++ gcc/config/gnu.h
@@ -19,14 +19,6 @@ You should have received a copy of the GNU General Public 
License
 along with GCC.  If not, see .
 */
 
-/* Provide GCC options for standard feature-test macros.  */
-#undef CPP_SPEC
-#define CPP_SPEC "%{posix:-D_POSIX_SOURCE}"
-
-/* Default C library spec.  */
-#undef LIB_SPEC
-#define LIB_SPEC "%{pthread:-lpthread} %{pg|p|profile:-lc_p;:-lc}"
-
 #undef GNU_USER_TARGET_OS_CPP_BUILTINS
 #define GNU_USER_TARGET_OS_CPP_BUILTINS()  \
 do {   \
--- gcc/config/i386/gnu.h
+++ gcc/config/i386/gnu.h
@@ -27,11 +27,11 @@ along with GCC.  If not, see .
 #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|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}"
 #else
 #define 



Re: [IMPORTANT] Ideas for Summer of Code 2016


2016-02-24

Thread
Thomas Schwinge

Hi!

On Wed, 10 Feb 2016 15:59:08 +0100, Giuseppe Scrivano  wrote:
> Hi everyone!
> 
> Google is accepting applications for the next Summer of Code and as
> usual we are going to apply for it.

Thanks for taking care of this, again!


> We should start thinking about a list of ideas for the next Summer of
> Code and potential mentors.
> 
> This is the list of ideas we had last year:
> 
>   http://www.gnu.org/software/soc-projects/ideas-2015.html
> 
> Is there anything left undone that can be reused this year?

Please copy the section for GNU Hurd:
.


Grüße
 Thomas


signature.asc
Description: PGP signature





Re: [gscriv...@gnu.org: [IMPORTANT] Ideas for Summer of Code 2016]


2016-02-24

Thread
Thomas Schwinge

Hi!

On Sun, 14 Feb 2016 11:40:30 +0100, Justus Winter 
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting Samuel Thibault (2016-02-10 19:10:58)
> > Any ideas/mentors for the summer of code?
> 
> I'd be happy to mentor someone.

Great; thanks!

> I went over the list of our project ideas, and the ones I'd like to
> see tackled the most are: [...]

:-) Taking you at your word:

commit 4f6e25bae59835cb402597fc82a8029f6d56a3c9
Author: Thomas Schwinge <tho...@codesourcery.com>
Date:   Wed Feb 24 20:40:40 2016 +0100

GSoC preparations

id:"20160214104030.10353.84...@thinkbox.jade-hamburg.de"
---
 community/gsoc/project_ideas.mdwn  | 16 
 community/gsoc/project_ideas/driver_glue_code.mdwn | 12 ++--
 community/gsoc/project_ideas/package_manager.mdwn  |  6 +++---
 community/gsoc/project_ideas/secure_chroot.mdwn| 16 ++--
 community/gsoc/project_ideas/virtualization.mdwn   | 12 ++--
 community/gsoc/project_ideas/xattr.mdwn|  4 ++--
 6 files changed, 47 insertions(+), 19 deletions(-)

diff --git community/gsoc/project_ideas.mdwn community/gsoc/project_ideas.mdwn
index 643a424..7338d57 100644
--- community/gsoc/project_ideas.mdwn
+++ community/gsoc/project_ideas.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
-Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015,
+2016 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -97,9 +97,13 @@ All project ideas inlined:
 
 project_ideas:
 
-  "community/gsoc/project_ideas/physical_memory_management
+  "community/gsoc/project_ideas/virtualization
+  community/gsoc/project_ideas/secure_chroot
+  community/gsoc/project_ideas/package_manager
+  community/gsoc/project_ideas/xattr
+  community/gsoc/project_ideas/driver_glue_code
+  community/gsoc/project_ideas/physical_memory_management
   community/gsoc/project_ideas/language_bindings
-  community/gsoc/project_ideas/virtualization
   community/gsoc/project_ideas/file_locking
   community/gsoc/project_ideas/gdb
   community/gsoc/project_ideas/tcp_ip_stack
@@ -110,8 +114,6 @@ project_ideas:
   community/gsoc/project_ideas/xmlfs
   community/gsoc/project_ideas/unionfs_boot
   community/gsoc/project_ideas/lexical_dot-dot
-  community/gsoc/project_ideas/secure_chroot
-  community/gsoc/project_ideas/package_manager
   community/gsoc/project_ideas/download_backends
   community/gsoc/project_ideas/maxpath
   community/gsoc/project_ideas/gnat
@@ -122,9 +124,7 @@ project_ideas:
   community/gsoc/project_ideas/testsuites
   community/gsoc/project_ideas/testing_framework
   community/gsoc/project_ideas/libcap
-  community/gsoc/project_ideas/xattr
   community/gsoc/project_ideas/valgrind
-  community/gsoc/project_ideas/driver_glue_code
   community/gsoc/project_ideas/dtrace
   community/gsoc/project_ideas/libdiskfs_locking"
 
diff --git community/gsoc/project_ideas/driver_glue_code.mdwn 
community/gsoc/project_ideas/driver_glue_code.mdwn
index 8581c7c..0f92159 100644
--- community/gsoc/project_ideas/driver_glue_code.mdwn
+++ community/gsoc/project_ideas/driver_glue_code.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software 
Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2016 Free Software
+Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -66,8 +67,15 @@ To be able to work on the framework,
 the student will also have to get a good understanding of certain aspects of 
Hurd,
 such as memory management for example.
 
-Possible mentors: Zheng Da, Samuel Thibault (youpi)
+Possible mentors: Justus Winter (teythoon), Samuel Thibault (youpi)
 
 Exercise: Get one of the not yet integrated Linux network card drivers to work.
 (Note: This should be straightforward,
 once you have the framework properly built and set up...)
+
+---
+
+
+# 2016-02-14, Justus Winter
+
+`s/dde/rump/g` of course.
diff --git community/gsoc/project_ideas/package_manager.mdwn 
community/gsoc/project_ideas/package_manager.mdwn
index 721f6d0..63a1d7c 100644
--- community/gsoc/project_ideas/package_manager.mdwn
+++ community/gsoc/project_ideas/package_manager.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2013, 2014, 2016 Free Software
+Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" tex



Re: Not running into expected SIGSEGV


2016-02-23

Thread
Thomas Schwinge

Hi!

Samuel's MTA (labri.fr) told me that it's "not permissible" to attach
*.exe* files to emails.  I you didn't receive that file, you can also
copy it from darnassus:~tschwinge/stack_check1.exe, or ask me to send it
"scrambled".

On Tue, 23 Feb 2016 11:37:58 +0100, I wrote:
> The attached program, stack_check1.exe, is supposed to terminated with a
> SIGSEGV (endless recursion, if I remember correctly the Ada source code
> From the GCC testsuite).  (Samuel, that's the issue that I vaguely/in a
> hurry described to you at FOSDEM, which impacts my GCC testing.)
> 
> I do get the SIGSEGV with old 1:0.6.git20150704-2 Hurd packages
> installed, in a system that is otherwise up to date.  Booting with more
> recent Hurd packages from 
> installed, the stack_check1.exe process then just hangs.  (Need to kill
> -KILL it, C-c will make the session/PTY hang or something.)  If I
> remember correctly (it's been some months...), there also was erratic
> behavior to be observed when I bisected earlier Hurd package versions:
> some worked (SIGSEGV) some didn't (hang).
> 
> I couldn't figure out any pattern from looking at the diffs between the
> respective Hurd packages' sources.  What I did not consider is which
> glibc versions the Hurd packages have been built against (statically
> linked, in part) -- which might be relevant, too.
> 
> With recent 1:0.7.git20160214-2 Hurd packages installed:
> 
> $ ./stack_check1.exe
> [hangs]
> 
> $ rpctrace ./stack_check1.exe
> [...]
> task51(pid1023)->vm_map (0 2097152 0 1  (null) 0 1 0 7 1) = 0 196608
> task51(pid1023)->vm_deallocate (196608 851968) = 0 
> task51(pid1023)->vm_deallocate (2097152 196608) = 0 
> task51(pid1023)->vm_protect (1048576 135168 0 3) = 0 
> task51(pid1023)->mach_port_deallocate (pn{ 24}) = 0 
> task51(pid1023)->mach_port_deallocate (pn{ 24}) = 0 
>   68<--72(pid-1)-> 2400 (rpctrace: ../../utils/rpctrace.c:863: 
> print_contents: Assertion `inp->msgh_bits & 0x8000U' failed.
> Aborted
> 
> (Yay, another rpctrace issue.)  ;-)
> 
> $ gdb -q ./stack_check1.exe
> Reading symbols from ./stack_check1.exe...done.
> (gdb) r
> Starting program: /media/erich/home/thomas/stack_check1.exe 
> [New Thread 1026.5]
> [New Thread 1026.6]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
> 2   
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:
>  No such file or directory.
> (gdb) info threads
>   Id   Target Id Frame 
>   6Thread 1026.6 0x080614ec in stack_check1.consume_stack ()
>   5Thread 1026.5 0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
> * 4Thread 1026.4 0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
>   3bogus thread id 3 Can't fetch registers from thread bogus thread 
> id 3: No such thread
> 
> (Yay, another GDB issue.)  ;-)
> 
> (gdb) thread apply all bt
> 
> Thread 6 (Thread 1026.6):
> #0  0x080614ec in stack_check1.consume_stack ()
> #1  0x08061540 in stack_check1.consume_stack ()
> #2  0x08061540 in stack_check1.consume_stack ()
> #3  0x08061540 in stack_check1.consume_stack ()
> #4  0x08061540 in stack_check1.consume_stack ()
> #5  0x08061540 in stack_check1.consume_stack ()
> #6  0x08061540 in stack_check1.consume_stack ()
> #7  0x08061540 in stack_check1.consume_stack ()
> [...]
> #251 0x08061540 in stack_check1.consume_stack ()
> #252 0x08061540 in stack_check1.consume_stack ()
> #253 0x08061540 in stack_check1.consume_stack ()
> #254 0x08061639 in stack_check1.t ()
> #255 0x08060f72 in system.tasking.stages.task_wrapper (self_id=0x8082eb0) 
> at s-tassta.adb:1262
> #256 0x01042b1f in entry_point (self=0x8085fb0, start_routine=0x8060e20 
> , arg=0x8082eb0)
> at ./pthread/pt-create.c:64
> #257 0x in ?? ()
> 
> Thread 5 (Thread 1026.5):
> #0  0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
> #1  0x0107e0c6 in __mach_msg (msg=0x2802f20, option=3, send_size=32, 
> rcv_size=4096, rcv_name=56, timeout=0, notify=0) at msg.c:110
> #2  0x0107e704 in __mach_msg_server_timeout (demux=0x108e4c0 
> , max_size=4096, rcv_name=56, option=0, timeout=0) at 
> msgserver.c:150
> #3  0x0107e7c4 in __mach_msg_server (demux=0x108e4c0 , 
> max_size=4096, rcv_name=56) at msgserver.c:195
> #4  0x0108e5ae in _hurd_msgport_receive () at msgportdemux.c:67
> #5  0x01042b1f in entry_point (self=0x80819b0, start_routine=0x108e550 
> <_hurd_msgport_receive>, arg=0x0) at ./pthread/pt-create.c:64
> #6  



Hurd: Make gdb/reply_mig_hack.awk script compatible to "mawk" (was:	[RFC] GDB Hurd Fixes)


2016-01-12

Thread
Thomas Schwinge

Hi!

On Mon, 6 Jan 2014 17:56:27 +0100, I wrote:
> On Fri, 20 Sep 2013 11:17:08 -0400, David Michael <fedora@gmail.com> 
> wrote:
> > mig has stopped using the "auto" keyword in its output.[1]
> > Without that keyword, gdb/reply_mig_hack.awk fails to match a
> > necessary pattern and outputs a bad gdb/process_reply_S.c file.

> commit d8131897afba28934ced82c507114123027a40f8
> Author: Thomas Schwinge <tho...@codesourcery.com>
> Date:   Mon Jan 6 15:56:33 2014 +0100
> 
> Hurd: Adapt to changed MIG output.
> 
>   gdb/
>   * reply_mig_hack.awk: Don't expect to see the auto keyword.
> 
> Based on patch by David Michael <fedora@gmail.com>.
> 
> diff --git gdb/reply_mig_hack.awk gdb/reply_mig_hack.awk
> index 97e080f..e137a27 100644
> --- gdb/reply_mig_hack.awk
> +++ gdb/reply_mig_hack.awk
> @@ -78,9 +78,9 @@ parse_phase == 4 {
>print; next;
>  }
>  
> -parse_phase == 5 && /^[ \t]*(auto|static) const mach_msg_type_t/ {
> +parse_phase == 5 && /^[ \t]*(auto |static |)const mach_msg_type_t/ {
># The type check structure for an argument.
> -  arg_check_name[num_checks] = $4;
> +  arg_check_name[num_checks] = $(NF - 2);
>num_checks++;
>print; next;
>  }

Turns out that the "mawk" AWK implementation doesn't like that regular
expression:

mawk: [...]/gdb/reply_mig_hack.awk: line 98: regular expression compile 
failed (missing operand)

I didn't check it against the AWK language definition, but instead just
made the gdb/reply_mig_hack.awk script compatible to "mawk"; pushed:

commit 5eddd57823971bdb54f957d10c11ff3fc9f97b1e
Author: Thomas Schwinge <tho...@codesourcery.com>
Date:   Tue Jan 12 12:53:09 2016 +0100

Hurd: Make gdb/reply_mig_hack.awk script compatible to "mawk"

The "mawk" AWK implementation did't like that regular expression:

mawk: [...]/gdb/reply_mig_hack.awk: line 98: regular expression compile 
failed (missing operand)

gdb/
* reply_mig_hack.awk: Rewrite one regular expression.
---
 gdb/ChangeLog  | 4 
 gdb/reply_mig_hack.awk | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git gdb/ChangeLog gdb/ChangeLog
index 099a9a9..73b001c 100644
--- gdb/ChangeLog
+++ gdb/ChangeLog
@@ -1,3 +1,7 @@
+2016-01-12  Thomas Schwinge  <tho...@codesourcery.com>
+
+   * reply_mig_hack.awk: Rewrite one regular expression.
+
 2016-01-11  Mike Frysinger  <vap...@gentoo.org>
 
* acinclude.m4: Include new warning.m4 file.
diff --git gdb/reply_mig_hack.awk gdb/reply_mig_hack.awk
index 1e2387a..e4c513b 100644
--- gdb/reply_mig_hack.awk
+++ gdb/reply_mig_hack.awk
@@ -95,7 +95,7 @@ parse_phase == 4 {
   print; next;
 }
 
-parse_phase == 5 && /^[ \t]*(auto |static |)const mach_msg_type_t/ {
+parse_phase == 5 && /^[ \t]*(auto |static )?const mach_msg_type_t/ {
   # The type check structure for an argument.
   arg_check_name[num_checks] = $(NF - 2);
   num_checks++;


Grüße
 Thomas


signature.asc
Description: PGP signature





 (was: Small web server for	the Hurd)


2016-01-11

Thread
Thomas Schwinge

Hi!

On Sun, 22 Nov 2015 01:01:09 +0100, Richard Braun  wrote:
> It looks like some changes in the past months have increased the
> severity of some bugs apache is having when spawning CGIs, resulting
> in unkillable processes and the freezing of the parent apache process.
> This had the effect of making the darnassus.sceen.net server almost
> unusable publicly.

:-/

> Since I don't have the time to hunt that bug, I decided to replace the
> web server, and unfortunately, the already packaged ones are either non
> fonctional, or don't build on the Hurd.
> 
> As a result, I have packaged the small thttpd web server, or more
> precisely, its sthttpd fork.

..., which has been installed on darnassus for some time already.  Due to
a slightly different CGI setup compared to apache2, anything related to
CGI has not been working.  I now finally fixed this, and checked login
using a local user ("other": "localsignin"), and login using OpenID
(), did a edit/commit with each of
these ("tschwinge going to FOSDEM", yay!), and checked wiki search (had
been reported broken by Justus).

So,  again is functional.


Grüße
 Thomas


signature.asc
Description: PGP signature





Rework *.msgids handling when neither client nor server stubs are	required (was: [SCM] GNU Mach branch, master,	updated. v1.5-32-g255c47e)


2015-10-31

Thread
Thomas Schwinge

Hi!

On Sun, 31 May 2015 16:01:54 +, Justus Winter 
<4win...@informatik.uni-hamburg.de> wrote:
> commit 255c47e669819f153c722c98a230f6fe4e6ece08
> Author: Justus Winter <4win...@informatik.uni-hamburg.de>
> Date:   Sun May 25 16:26:42 2014 +0200
> 
> Include the notify protocol in `gnumach.msgids'
> 
> * Makefrag.am (gnumach.msgids): Add `notify.msgids' as prerequisite.
> * Makerules.mig.am: Add rule to generate the list of message ids when
> neither the client nor the server stubs are required.
> * ipc/notify.defs: New file.

A minor fix-up; pushed:

commit a42c4ee0845b79fb70c2206982347c1b0c093f87
Author: Thomas Schwinge <tho...@codesourcery.com>
Date:   Sat Oct 31 12:44:06 2015 +0100

Rework *.msgids handling when neither client nor server stubs are required

Originally added in commit 255c47e669819f153c722c98a230f6fe4e6ece08, but 
"make
distcheck" didn't like that:

[...]
ERROR: files left in build directory after distclean:
./ipc/notify.msgids
Makefile:7489: recipe for target 'distcleancheck' failed
make[1]: *** [distcleancheck] Error 1
make[1]: Leaving directory 
'[...]/gnumach/release.build/gnumach-1.5/_build/sub'
Makefile:7416: recipe for target 'distcheck' failed
make: *** [distcheck] Error 1

Instead of special-casing that, generalize the Makefile rules.

* Makefrag.am (nodist_lib_dep_tr_for_defs_a_SOURCES): Add
ipc/notify.none.defs.c.
(nodist_libkernel_a_SOURCES): Add ipc/notify.none.msgids.
(gnumach.msgids): Remove ipc/notify.msgids prerequisite.
* Makerules.mig.am (%.msgids): Remove rule, and instead...
(%.none.defs.c, %.none.msgids): ... add these rules.
---
 Makefrag.am  | 11 +--
 Makerules.mig.am | 21 ++---
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git Makefrag.am Makefrag.am
index b9d96c5..823ece5 100644
--- Makefrag.am
+++ Makefrag.am
@@ -545,11 +545,18 @@ nodist_libkernel_a_SOURCES += \
 #  kern/mach_debug.server.defs
 #  kern/mach_host.server.defs
 
+# Stand-alone rule to generate the list of message ids when neither
+# the client nor the server stubs are required.
+nodist_lib_dep_tr_for_defs_a_SOURCES += \
+   ipc/notify.none.defs.c
+nodist_libkernel_a_SOURCES += \
+   ipc/notify.none.msgids
+#  ipc/notify.none.defs
+
 # rpctrace can make use of that.
 MOSTLYCLEANFILES += \
gnumach.msgids
-gnumach.msgids: $(filter %.msgids,$(nodist_libkernel_a_SOURCES)) \
-   ipc/notify.msgids
+gnumach.msgids: $(filter %.msgids,$(nodist_libkernel_a_SOURCES))
$(AM_V_at) cat $^ > $@.new
$(AM_V_GEN) mv $@.new $@
 # `exec_' prefix, so that we don't try to build that file during when running
diff --git Makerules.mig.am Makerules.mig.am
index 085b247..8ae6555 100644
--- Makerules.mig.am
+++ Makerules.mig.am
@@ -74,29 +74,28 @@ lib_dep_tr_for_defs_a_CPPFLAGS = $(AM_CPPFLAGS) \
 %.server.defs.c: %.srv
$(AM_V_at) rm -f $@
$(AM_V_GEN) cp -p $< $@
-%.user.defs.c: %.cli
-   $(AM_V_at) rm -f $@
-   $(AM_V_GEN) cp -p $< $@
 %.server.h %.server.c %.server.msgids: 
lib_dep_tr_for_defs_a-%.server.defs.$(OBJEXT)
$(MIGCOM_V) $(MIGCOM) $(MIGCOMFLAGS) $(MIGCOMSFLAGS)\
  -sheader $*.server.h -server $*.server.c  \
  -list $*.server.msgids\
  < $<
+%.user.defs.c: %.cli
+   $(AM_V_at) rm -f $@
+   $(AM_V_GEN) cp -p $< $@
 %.user.h %.user.c %.user.msgids: lib_dep_tr_for_defs_a-%.user.defs.$(OBJEXT)
$(MIGCOM_V) $(MIGCOM) $(MIGCOMFLAGS) $(MIGCOMUFLAGS)\
  -user $*.user.c -header $*.user.h \
  -list $*.user.msgids  \
  < $<
-
-vpath %.defs $(top_srcdir)
-
 # Stand-alone rule to generate the list of message ids when neither
 # the client nor the server stubs are required.
-%.msgids: %.defs
-   $(MIGCOM_V) $(CPP) $(AM_CPPFLAGS) $(CPPFLAGS) -E $< \
-   | $(MIGCOM) $(MIGCOMFLAGS) $(MIGCOMSFLAGS)  \
- -sheader /dev/null -server /dev/null  \
- -list "$*.msgids"
+%.none.defs.c: %.defs
+   $(AM_V_at) rm -f $@
+   $(AM_V_GEN) cp -p $< $@
+%.none.msgids: lib_dep_tr_for_defs_a-%.none.defs.$(OBJEXT)
+   $(MIGCOM_V) $(MIGCOM) $(MIGCOMFLAGS)\
+ -list $*.none.msgids  \
+ < $<
 
 # This is how it should be done, but this is not integrated into GNU Automake
 # and is missing automatic inter-file dependency management because of that.


Grüße
 Thomas


signature.asc
Description: PGP signature





GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released


2015-10-31

Thread
Thomas Schwinge

Hi!

Please see
.

Text-only version:

| GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released.
| 
| We're pleased to announce new releases!
| 
| GNU Hurd 0.7, NEWS:
| 
| Version 0.7 (2015-10-31)
| 
| 
| The node cache in ext2fs has been improved, generalized, and moved to
| libdiskfs.  It is now also used by isofs and fatfs.
| 
| 
| The native fakeroot tool has been greatly improved.  It now handles
| named sockets, and multiple corner cases related to permissions were
| identified and fixed.
| 
| 
| A new utility `rpcscan' has been introduced.  It scans Mach servers
| and displays the RPCs handled by the associated demuxer.
| 
| 
| A long-standing synchronization issue involving the filesystem
| translators, libdiskfs, and libpager has been identified and fixed.
| 
| 
| The code has been updated to work with newer versions of the compiler
| and libc, and numerous bugs have been fixed throughout the code.
| 
| Release tarballs may be downloaded from ftp://ftp.gnu.org/gnu/hurd/, 
http://ftp.gnu.org/gnu/hurd/, or checked out of Git, 
http://git.savannah.gnu.org/cgit/hurd/hurd.git. SHA1 checksums:
| 
| a735a07687f7996face3bd310af2254192a02f40  hurd-0.7.tar.bz2
| d10b3c1de191ac88425aa30a03c4130e2a883b14  hurd-0.7.tar.bz2.sig
| 62032e04bf6b22e4c874772f1f77d5678d916054  hurd-0.7.tar.gz
| 7fafd66e0003ea3768f76bd597e617bdc202e312  hurd-0.7.tar.gz.sig
| 
| The GNU Hurd is the GNU project's replacement for the Unix kernel. It is 
a collection of servers that run on the Mach microkernel to implement file 
systems, network protocols, file access control, and other features that are 
implemented by the Unix kernel or similar kernels (such as Linux). More 
detailed: documentation, what is the GNU Hurd.
| 
| GNU Mach 1.6, NEWS:
| 
| Version 1.6 (2015-10-31)
| 
| 
| The code has been updated to work with newer versions of the compiler,
| and numerous bugs have been fixed throughout the code.
| 
| 
| The lock debugging infrastructure has been revived and improved, and
| many locking issues have been fixed.
| 
| 
| The IPC tables and the hash table mapping objects to IPC entries have
| been replaced by radix trees.  This addresses a scalability issue, as
| IPC tables required huge amounts of continuous virtual kernel memory.
| 
| 
| The kernel now allows non-privileged users to wire a small amount of
| memory.
| 
| 
| A bug hindering the eviction of inactive pages by the pageout daemon
| has been identified and fixed.
| 
| 
| The kernel now keeps timestamps relative to the system boot time.
| Among other things this fixes bogus uptime readings if the system time
| is altered.
| 
| 
| A reference leak in the exception handling mechanism has been
| identified and fixed.
| 
| 
| ANSI escape sequences are now handled when using `printf'.  This fixes
| the formatting of messages printed by various Linux drivers.
| 
| Release tarballs may be downloaded from ftp://ftp.gnu.org/gnu/gnumach/, 
http://ftp.gnu.org/gnu/gnumach/, or checked out of Git, 
http://git.savannah.gnu.org/cgit/hurd/gnumach.git. SHA1 checksums:
| 
| 73e09c43955ef2e3459b2877b5e6d6bbe517b8c3  gnumach-1.6.tar.bz2
| 96ff426b3b94acf327a88f25c80ab5b5f26ed94a  gnumach-1.6.tar.bz2.sig
| 448cd88974a5264736c900691c9ab62a810aff28  gnumach-1.6.tar.gz
| e06e733ad11f2e048dd9ad3348c2d3100be26078  gnumach-1.6.tar.gz.sig
| 
| GNU Mach is the GNU distribution of the Mach microkernel, upon which a 
GNU Hurd system is based. The microkernel provides an Inter Process 
Communication (IPC) mechanism that the Hurd uses to define interfaces for 
implementing in a distributed multi-server fashion the services a traditional 
operating system kernel provides. More detailed: documentation.
| 
| GNU MIG 1.6, NEWS:
| 
| Version 1.6 (2015-10-31)
| 
| 
| * MIG now emits RPC lookup functions that are declared `static inline'
|   improving compatibility with newer dialects of C.
| 
| Release tarballs may be downloaded from ftp://ftp.gnu.org/gnu/mig/, 
http://ftp.gnu.org/gnu/mig/, or checked out of Git, 
http://git.savannah.gnu.org/cgit/hurd/mig.git. SHA1 checksums:
| 
| a9a4b5666834afe8fb861453c5b3ef324201f1d3  mig-1.6.tar.bz2
| 93562c45bbda40ad31f74f6f2fd0c064ef8f0ec5  mig-1.6.tar.bz2.sig
| 6e937a35229da02e9e739d75a03020e24a1b5297  mig-1.6.tar.gz
| fc25bb9652406675fed63c4581493a6fc39d9690  mig-1.6.tar.gz.sig
| 
| GNU MIG is the GNU distribution of the Mach 3.0 Interface Generator 
(MIG). This tool translates Remore Procedure Call (RPC) definition files to C 
code, and is required to compile any packages that are receiving or invoking 
RPCs, such as GNU Mach, GNU Hurd, and the GNU C Library (glibc) when compiled 
for the Hurd. More detailed: documentation.
| 
| glibc-2.19-hurd+libpthread-20151031
| 
| Snapshot 



Re: glibc-2.19-hurd+libpthread-20150515


2015-10-30

Thread
Thomas Schwinge

Hi!

In context of preparing a new glibc-hurd+libpthread snapshot,
<http://news.gmane.org/find-root.php?message_id=%3C20151012215601.GS2989%40var.home%3E>,
is the procedure to merge/cherry-pick the recent patches from
libpthread's master branch into its master-glibc branch?  Could you
please do and test that?

And/or should we...

On Fri, 15 May 2015 16:50:29 +0200, Samuel Thibault <samuel.thiba...@gnu.org> 
wrote:
> Thomas Schwinge, le Fri 15 May 2015 16:46:43 +0200, a écrit :
> > On Thu, 7 May 2015 01:43:05 +0200, Samuel Thibault 
> > <samuel.thiba...@gnu.org> wrote:
> > > I have prepared a master-glibc branch in the libpthread repo.
> > 
> > Thanks!  However, shouldn't that just be libpthread's master branch,
> > nowadays?

... pursue this?

> > (Assuming the idea still is that libpthread is only to be
> > built as part of glibc's build process?)
> 
> With that assumption, yes.

Didn't we agree that's the only viable thing to do, or what have I
forgotten?


Grüße
 Thomas


signature.asc
Description: PGP signature





Re: Rolling new releases


2015-10-27

Thread
Thomas Schwinge

Hi!

On Mon, 26 Oct 2015 20:57:25 +0100, Justus Winter 
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting Justus Winter (2015-10-05 16:39:46)
> > as agreed earlier, we're trying to produce two releases a year.  We
> > released GNU Mach 1.5, GNU MIG 1.5, and GNU Hurd 0.6 in April, hence
> > it is time for our next release :)
> > 
> > I have curated a list of noteworthy changes and populated the NEWS
> > files with them.

Many thanks!

> > Feel free to commit or suggest any changes.  As a
> > reminder to anyone (including me ;), feel free to add a note to NEWS
> > along with any significant change you propose.
> 
> this your friendly yet mildly annoyed reminder.  It has been three
> weeks now, and there is not much October left to work with.  We agreed
> on bi-yearly releases, and I consider reasonably up-to-date snapshots
> important for downstream users.

ACK.  I've been working on that last weekend, but had too many
interruptions, so couldn't complete.  Will get it done this week.


Grüße
 Thomas


signature.asc
Description: PGP signature





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


2015-10-12

Thread
Thomas Schwinge

Hi Samuel!

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
> 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.

ACK.  Thanks, I'll take care of your patch.

>   * 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


Grüße,
 Thomas


signature.asc
Description: PGP signature





Re: "Recent changes" links redirect to 404


2015-10-07

Thread
Thomas Schwinge

Hi!

On Mon, 28 Sep 2015 23:54:01 +0300, gk.p...@gmail.com wrote:
> When going to the "recent changes" at the hurd wiki, and clicking to one
> of the pages I am redirected to a "404 - not found" page. This also
> holds true for the hurd wiki at sceen.net.

Thanks for reporting this -- it seems the system hosting the wiki system
has been re-installed a while ago, and I needed to
re-install/re-configure some things.  Doing that, I accidentally nuked a
few configuration files, and figuring out what needs to be done, this was
a good "reminder" on how that setup is done; I have then updated

with some more details.  ;-)

Anyway, things should be working again.  I tested: git push; web edit
with local user; web edit with launchpad.net OpenID login; some CGI
functionality, including the search box in the upper right corner.


Grüße,
 Thomas


signature.asc
Description: PGP signature





Re: bug-hurd mailing list


2015-10-07

Thread
Thomas Schwinge

Hi!

On Sat, 03 Oct 2015 00:05:59 +0200, I wrote:
> On Wed, 30 Sep 2015 22:27:04 +0200, Robert Millan  wrote:
> > I suspect the
> > list server isn't forwarding neither your mails nor mine:
> > 
> >1. My previous mail doesn't show up in the list archive:
> > 
> >   https://lists.gnu.org/archive/html/bug-hurd/2015-09/index.html
> > 
> >2. I received a direct copy of your mail, but I didn't receive it
> >   through the list. And it doesn't show up in the list archives
> >   either!
> > 
> > Anyone knows what's going on? :-)
> 
> I don't have any insights into the GNU email infrastructure, but I can
> confirm that
>  is
> missing messages, that
>  is "404
> Not Found" even though there have been messages posted and delivered
> through the bug-hurd list, and that  is
> also stuck at "635184 Sep 29 09:56 2015-09".  Looking at a few messages'
> Received headers, there are big delays (many hours) between GNU machines.

OK, I learned from  that indeed there
"currently" are problems with lists.gnu.org; they're working on it.


Grüße,
 Thomas


signature.asc
Description: PGP signature





bug-hurd mailing list (was: Shortest path to significant improvement	in hardware support)


2015-10-02

Thread
Thomas Schwinge

Hi!

On Wed, 30 Sep 2015 22:27:04 +0200, Robert Millan  wrote:
> I suspect the
> list server isn't forwarding neither your mails nor mine:
> 
>1. My previous mail doesn't show up in the list archive:
> 
>   https://lists.gnu.org/archive/html/bug-hurd/2015-09/index.html
> 
>2. I received a direct copy of your mail, but I didn't receive it
>   through the list. And it doesn't show up in the list archives
>   either!
> 
> Anyone knows what's going on? :-)

I don't have any insights into the GNU email infrastructure, but I can
confirm that
 is
missing messages, that
 is "404
Not Found" even though there have been messages posted and delivered
through the bug-hurd list, and that  is
also stuck at "635184 Sep 29 09:56 2015-09".  Looking at a few messages'
Received headers, there are big delays (many hours) between GNU machines.


Grüße,
 Thomas


signature.asc
Description: PGP signature





Re: [PATCH v3] Fix race condition in ext2fs when remounting


2015-07-27

Thread
Thomas Schwinge

Hi!

First, thanks for working on this issue!

On Sat, 25 Jul 2015 14:06:24 +0200, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 What happened to the corresponding fatfs change though?  Isofs is
 read-only, and tmpfs' diskfs_reload_global_state is a nop too.  So
 modulo the missing fatfs fix this patch looks good to me.

Justus, thanks for working with James, reviewing his patch!


 Samuel, Thomas, is this still a smallish change that we can
 just merge, or do we need to do the paperwork now?

I'm afraid, we'll have to...  :-/

James, are you familiar with the FSF copyright assignment process?  For
example, see http://www.gnu.org/licenses/why-assign.en.html, and
https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html.  If
that is OK for you, the simplest thing to do is to use the form to assign
to the FSF all past and future contributions to the respective GNU
packages.  See the attached request-assign.future.  After sending this
information to ass...@gnu.org (please put me in CC so that I can track
it), you'll receive a form to sign, and then mail this to the FSF, or
send a scan of it via email, as applicable.

For »program or package you're contributing to«, I suggest to specify all
of: Mach, MIG, Hurd, glibc.  This is to avoid having to repeat the whole
procedure when touching those closely related packages, working on other
parts of the Hurd code base later on.


Grüße,
 Thomas


Please email the following information to ass...@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
--
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]


signature.asc
Description: PGP signature





Re: glibc build log (TLS-related issue)


2015-06-24

Thread
Thomas Schwinge

Hi!

On Tue, 23 Jun 2015 15:10:12 +0200, Samuel Thibault samuel.thiba...@gnu.org 
wrote:
 Ok, the change which made my glibc work with static linking is:

What's the failure mode?  (So that it can be added to
http://darnassus.sceen.net/~hurd-web/open_issues/glibc/, or a new issue
be filed.)

 --host=i586-gnu --build=i586-gnu

(For what it's worth, I'm still testing with i486-gnu...)  ;-)

 I guess the default i686 variant introduces bugs.


Grüße,
 Thomas


signature.asc
Description: PGP signature





Re: glibc build log (TLS-related issue)


2015-06-24

Thread
Thomas Schwinge

Hi!

On Wed, 24 Jun 2015 11:37:00 +0300, Manolis Ragkousis manolis...@gmail.com 
wrote:
 On 23 June 2015 at 16:10, Samuel Thibault samuel.thiba...@gnu.org wrote:
  Ok, the change which made my glibc work with static linking is:
 
  --host=i586-gnu --build=i586-gnu
 
  I guess the default i686 variant introduces bugs.
 
 
 Trying to run make lib in darnassus using i586-gnu, with the debian
 sources, fails with
 
 /home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
 function `__strcspn_sse42':
 (.text.sse4.2+0x1d73): undefined reference to `__strcspn_ia32'
 /home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
 function `__strpbrk_sse42':
 (.text.sse4.2+0x1eb0): undefined reference to `__strpbrk_ia32'
 /home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
 function `__strspn_sse42':
 (.text.sse4.2+0x1fe8): undefined reference to `__strspn_ia32'
 collect2: error: ld returned 1 exit status

That looks like something's going wrong with IFUNCs,
http://www.gnu.org/software/hurd/open_issues/ifunc.html.  What's your
exact configure command line?  In particular, are you using
--disable-multi-arch (if I remember correctly)?

 and the same command with the tarballs sources end up with
 
 http://paste.lisp.org/display/150437

That looks like https://sourceware.org/PR15605,
http://news.gmane.org/find-root.php?message_id=%3CE1VU3KH-00083u-04%40vasks.debian.org%3E,
http://news.gmane.org/find-root.php?message_id=%3CE1VU9tp-0007UR-IS%40vasks.debian.org%3E.


Grüße,
 Thomas


signature.asc
Description: PGP signature





Re: GSoC: Porting Guix to Hurd week 3+4 report.


2015-06-07

Thread
Thomas Schwinge

Hi!

On Thu, 04 Jun 2015 22:48:48 +0200, l...@gnu.org (Ludovic 
=?utf-8?Q?Court=C3=A8s?=) wrote:
 Manolis Ragkousis manolis...@gmail.com skribis:
 
  Hey Thomas, thank you for looking into this.

Many thanks to you as well as Ludo for your very helpful description and
instructions!  I've also spent an hour or two on the Guix manual.

  So let's start with the easy one. [...]
 
 Alternately, there’s a really easy way: grab the binary tarball and
 follow the steps at http://www.gnu.org/software/guix/download/ [...]

Did that.

 From there:
 
   git clone git://git.savannah.gnu.org/guix.git

(Per Manolis' suggestion, I'm using his GitHub repository.)

   cd guix
   git checkout wip-hurd
   guix environment guix

(Very pedantically, is that last commant completely correct?  My
understanding is that it sets up an environment for building the version
of the guix package that is current known to Guix, and not the version
From the checkout of the wip-hurd branch.  Of course, the underlying
assumption must be that these two versions have the same dependencies, so
their environment setup will be the same.)

   autoreconf  ./configure --localstatedir=/var \
 --with-libgcrypt-prefix=/gnu/store/...  make

(Not relevant right now, but why is the libgcrypt path not communicated
via the environment variables set up with guix environment?  Is that just
because there are no appropriate environment variables, or something
else?)  Also, I wanted to note that I, very guixy, computed that path
using:

$ guix build libgcrypt
warning: failed to install locale: Invalid argument
/gnu/store/r16v30hlw2d6n232rm37p53qy8rpr7f2-libgcrypt-1.6.3
/gnu/store/42ls5n7k6lai1k6xfa8v8wks7nn9g3gn-libgcrypt-1.6.3-debug

Next, I ran:

$ ./pre-inst-env guix build --target=i686-pc-gnu gcc-4.7 -K -c 8

  After it fails

..., and eventually reproduced the problem.  However, that took a series
of steps that was much longer that I had anticipated:

$ ls -lrt /var/log/guix/drvs/*/*
-rw-r--r-- 1 root root 14 Jun  7 18:41 
/var/log/guix/drvs/j1/lh997i7bzdkp9p41rxz3qbxim6wi5h-module-import.drv.bz2
-rw-r--r-- 1 root root 14 Jun  7 18:41 
/var/log/guix/drvs/sl/8ib3bv1mg2cfnr5yar3aac0y8v0vfc-module-import.drv.bz2
-rw-r--r-- 1 root root 14 Jun  7 18:41 
/var/log/guix/drvs/5x/a7hclvqnbmflx45k9l7lfiwr8af15a-module-import.drv.bz2
-rw-r--r-- 1 root root 14 Jun  7 18:43 
/var/log/guix/drvs/cx/ghd2z5f3s8is7dkd45xf7k0d5m6fmh-module-import-compiled.drv.bz2
-rw-r--r-- 1 root root 14 Jun  7 18:43 
/var/log/guix/drvs/ni/ybxnzzf3v97i8qkma1wsvcl7dss5cd-module-import-compiled.drv.bz2
-rw-r--r-- 1 root root 14 Jun  7 18:43 
/var/log/guix/drvs/px/m5fvm4hyd45jz957h0ygpf16wwmril-module-import-compiled.drv.bz2
-rw-r--r-- 1 root root 678428 Jun  7 18:46 
/var/log/guix/drvs/ws/mrcw363m1a1fyrl90v6lw7l9ps6x1g-gcc-4.8.4.tar.xz.drv.bz2
-rw-r--r-- 1 root root   6912 Jun  7 18:47 
/var/log/guix/drvs/4i/qpmrg8fp9skrlzqwh6sx10hl7nqmzx-findutils-4.4.2.tar.xz.drv.bz2
-rw-r--r-- 1 root root   1784 Jun  7 18:47 
/var/log/guix/drvs/g5/0yphc79id0q893cyj96w0fs7g4vwqh-acl-2.2.52.src.tar.xz.drv.bz2
-rw-r--r-- 1 root root  16872 Jun  7 18:47 
/var/log/guix/drvs/da/m2vq48wja8mfllyffv63l20z0nk3fy-findutils-4.4.2.drv.bz2
-rw-r--r-- 1 root root  92676 Jun  7 18:48 
/var/log/guix/drvs/8q/gkslsq79mj5yiqlyxsgiqff94gdasr-binutils-cross-boot0-2.25.drv.bz2
-rw-r--r-- 1 root root  99108 Jun  7 18:50 
/var/log/guix/drvs/m4/4gzq6psik91wpg641ciwiqdf4ws8dn-perl-5.16.1.drv.bz2
-rw-r--r-- 1 root root  13651 Jun  7 18:50 
/var/log/guix/drvs/gi/irgv2f3n6mkpv0fxvz0632abb5s4a0-xz-5.0.4.drv.bz2
-rw-r--r-- 1 root root 453999 Jun  7 18:53 
/var/log/guix/drvs/bd/ir2kw05i27qvb4cacj23s6ly0i10ki-gcc-cross-boot0-4.8.4.drv.bz2
-rw-r--r-- 1 root root 225864 Jun  7 18:54 
/var/log/guix/drvs/k2/33n6h7i9yk7xrjx2v8jnlpacy34pyj-linux-libre-headers-3.14.37.drv.bz2
-rw-r--r-- 1 root root  37213 Jun  7 18:55 
/var/log/guix/drvs/ay/s1lxgxkfwm4v4d7f5g9yq35q2frnin-texinfo-5.2.drv.bz2
-rw-r--r-- 1 root root  64985 Jun  7 18:57 
/var/log/guix/drvs/5y/nkn97vzsh25d0v5nlkmk0n1h63fqgl-gettext-boot0-0.19.4.drv.bz2
-rw-r--r-- 1 root root 245674 Jun  7 19:07 
/var/log/guix/drvs/5d/ki8gm79l8i8rnbmaj8nwqnfmk57v0q-glibc-intermediate-2.21.drv.bz2
-rw-r--r-- 1 root root 14 Jun  7 19:07 
/var/log/guix/drvs/lp/ps9by4yx1k74ndqmcr5s4izd1w2hlp-gcc-cross-boot0-wrapped-4.8.4.drv.bz2
-rw-r--r-- 1 root root  21686 Jun  7 19:08 
/var/log/guix/drvs/ly/qs87clgx12m3qs8s29w9704iifs1xm-m4-1.4.17.drv.bz2
-rw-r--r-- 1 root root  97293 Jun  7 19:09 
/var/log/guix/drvs/s8/lv0cl9rsnhybgirrjnxkdc4mx2a5rq-perl-5.16.1.drv.bz2
-rw-r--r-- 1 root root  12327 Jun  7 19:10 
/var/log/guix/drvs/2r/08d0n4jarsgkr6w7g6iz9lhycx4pq6-bison-3.0.4.drv.bz2
-rw-r--r-- 1 root root  16573 Jun  7 19:11 
/var/log/guix/drvs/4f/n2jvxqclaysfsy2lycnbd7inm558nr-bash-light-4.3.33.drv.bz2
-rw-r--r-- 1 root root 242768 Jun  7 19:21 




Re: GSoC: Porting Guix to Hurd week 3+4 report.


2015-06-02

Thread
Thomas Schwinge

Hi!

On Tue, 2 Jun 2015 17:06:48 +0300, Manolis Ragkousis manolis...@gmail.com 
wrote:
   [GCC build problem]

 I am attaching the complete build
 log and any related log.

Thanks, and I tried, but it's too cumbersome to handle that massive
amount of data in this way.  It'll be much easier if I can reproduce the
problem locally.

Shame on me, but I've never actively used/built Guix before.  I do know
about https://github.com/Phant0mas/Guix-on-Hurd, and that there must be
a Guix manual existing -- but can you help me get started, please?
(Pointers to specific parts of documentation are appreciated, of course.)

Is there a way to have the Guix build process create a shell script (or
some other linearized log of command invocations)?  At this point, the
latter would be earier for me to debug (evem reproduce?), compared to
really learning Guix -- which I'll be happy to do (and have been
meaning to do for a looong time...), but then it's probably going to take
longer for me to really get started.

Alternatively/additionally, I'd also appreciate a high-level
(coarse-grained) overview about the steps you're executing right now.
(Maybe that already documented somewhere, or is obvious from the Guix
build description files -- which I have not yet looked at.)  That is,
something like: 1) install GNU Mach headers: configure [...]  make
install [...], 2) install Hurd headers: [...], 3) build minimal cross-GCC
configured with [...] options: [...], and so on.


  Thanks for all the uneasy  frustrating work!
 
 You are welcome, I really enjoy working on it. :-).

Muahahaha!  ;-P The GNU toolchain can be a pain.  (Same for every other
non-trivial piece of software, heh...)  If you suffer through enough of
it, you might, one day, make an honest living out of what you've learned.
;-D


Grüße,
 Thomas


signature.asc
Description: PGP signature





refcounts_ref assertion failure


2015-05-10

Thread
Thomas Schwinge

Hi!

Running a binutils/GDB build on an up-to-date Debian GNU/Hurd system, I
just hit (mostly manually transcribed):

ext2fs: ../../libports/../libshouldbeinlibc/refcount.h:165: refcounts_ref: 
Assertion `! (r.hard == 1  r.weak == 0) || !refcount detected 
use-after-free!' failed.

Unfortunately, it was the root filesystem, so I couldn't start GDB to get
a proper backstack, etc.

Justed CCed, as you've lately ;-) (in Hurd timescale) been changing
some code using these refcounts -- just in case you'd happen to have any
suspicion.


Grüße,
 Thomas


signature.asc
Description: PGP signature





Re: [Qemu-devel] [PATCH v2] qemu-nbd: only send a limited number of	errno codes on the wire


2015-05-09

Thread
Thomas Schwinge

Hi!

With my GNU Hurd hat on:

On Fri,  8 May 2015 11:50:28 +0200, Paolo Bonzini pbonz...@redhat.com wrote:
 Right now, NBD includes potentially platform-specific error values in
 the wire protocol.

 This patch [...]

 Incoming values will in general match system errno values, but not
 on the Hurd which has different errno values (they have a subsystem
 code equal to 0x10 in bits 24-31).  The Hurd is probably not something
 to which QEMU has been ported, but still do the right thing and
 reverse-map the NBD errno values to the system errno values.
 
 The corresponding patch to the NBD protocol description can be found at
 http://article.gmane.org/gmane.linux.drivers.nbd.general/3154.

Thank you!  I added this information/links to
http://darnassus.sceen.net/~hurd-web/hurd/libstore/nbd_store/.


Grüße,
 Thomas


signature.asc
Description: PGP signature





GNU Mach 1.5 released


2015-04-15

Thread
Thomas Schwinge

Hi!

We're pleased to announce version 1.5 of GNU Mach, the GNU distribution
of the Mach microkernel,
http://www.gnu.org/software/hurd/microkernel/mach/gnumach.html.

GNU Mach is the microkernel upon which a GNU Hurd system is based.  It
provides an Inter Process Communication (IPC) mechanism that the Hurd
uses to define interfaces for implementing in a distributed multi-server
fashion the services a traditional operating system kernel provides.

GNU Mach runs on 32-bit x86 machines.  A version running on 64-bit x86
(x86_64) machines is in progress.  Volunteers interested in ports to
other architectures are sought; please contact us (see below) if you'd
like to help.

This new release bundles bug fixes and enhancements done since the last
release:

| Version 1.5 (2015-04-10)
| 
| Numerous cleanups and stylistic fixes of the code base.  Several
| problems have been identified using static analysis tools and
| subsequently been fixed.
| 
| A protected payload can now be associated with capabilities.  This
| payload is attached by the kernel to delivered messages and can be
| used to speed up the object lookup in the receiving task.
| 
| The kernel debugger can now parse ELF symbol tables, can be invoked
| over serial lines, gained two new commands and has received usability
| improvements.
| 
| The vm pageout policy has been tuned to accommodate modern hardware.
| 
| The kernel gained partial ACPI support on x86, enough to power down
| the system.

Many thanks to all the people who are helping!

Releases may be downloaded from ftp://ftp.gnu.org/gnu/gnumach/, or
checked out of Git, http://git.savannah.gnu.org/cgit/hurd/gnumach.git/.

The MD5 and SHA1 checksums for this distribution are:

3023f061532470da8850ff9be5c4fcdb  gnumach-1.5.tar.bz2
62aa5a3334532b606fc61bc0229f763c  gnumach-1.5.tar.bz2.sig
4d62717ca8f68dede42d82b162c3cefe  gnumach-1.5.tar.gz
604fa9741d0e2a2f0a1d354d06de4577  gnumach-1.5.tar.gz.sig

ed0b90ba8a15b497e879a2d441dff5ac41268a6c  gnumach-1.5.tar.bz2
48077efd12b95a3eab1c8ca5a91b9e0737848e81  gnumach-1.5.tar.bz2.sig
89d23ee7b306b3a7359ab2be864dd46a079ffc71  gnumach-1.5.tar.gz
7c6887d48dd0125040602d2297318af9b7608036  gnumach-1.5.tar.gz.sig

Please read the FAQ at http://www.gnu.org/software/hurd/faq.html.
Bug reports should be sent to bug-hurd@gnu.org or filed on
http://savannah.gnu.org/bugs/?group=hurd.  Requests for assistance
should be sent to help-h...@gnu.org or filed on
http://savannah.gnu.org/support/?group=hurd.  You can also find us on
the Freenode IRC network in the #hurd channel.


For the maintainers,
 Thomas


signature.asc
Description: PGP signature





GNU MIG 1.5 released


2015-04-15

Thread
Thomas Schwinge

Hi!

We're pleased to announce version 1.5 of GNU MIG, the GNU distribution of
the Mach 3.0 Interface Generator (MIG),
http://www.gnu.org/software/hurd/microkernel/mach/mig/gnu_mig.html.

This tool translates Remore Procedure Call (RPC) definition files to C
code, and is required to compile any packages that are receiving or
invoking RPCs, such as GNU Mach, GNU Hurd, and the GNU C Library (glibc)
when compiled for the Hurd.

This new release bundles bug fixes and enhancements done since the last
release:

| Version 1.5 (2015-04-10)
| 
| * Add support for protected payloads.  The new `intranpayload' option
|   can be used to specify a translation function translating payloads
|   to values of the translated type.  This function will be used
|   instead of the `intran' function to to look up the receiving object
|   of a message in a server.  This makes it easy to use the protected
|   payloads introduced in GNU Mach 1.5.
| 
| * Emit `X_server_routine' functions that can be inlined reducing the
|   message dispatch overhead.
| 
| * Improve support for variable-sized C strings.
| 
| * Fix a warning when compiling generated files.

Many thanks to all the people who are helping!

Releases may be downloaded from ftp://ftp.gnu.org/gnu/mig/, or checked
out of Git, http://git.savannah.gnu.org/cgit/hurd/mig.git/.

The MD5 and SHA1 checksums for this distribution are:

da7c75c32c2b67de78a24a7389369717  mig-1.5.tar.bz2
0e7d45b6c18562a8d64a1a73e59b942b  mig-1.5.tar.bz2.sig
eaabe5b01f02e0d383740055b54e1ece  mig-1.5.tar.gz
c91d7bd09d9520a91a7c4c95cd6089b0  mig-1.5.tar.gz.sig

8431799cd60a9b21e779dea3cb9c5c9b78b235b6  mig-1.5.tar.bz2
63c58db6470a25bdc408d6f8d60f7b1f81dfea1d  mig-1.5.tar.bz2.sig
50ddc0bc57b3af894637c2dd6e2c5bb4f930801c  mig-1.5.tar.gz
c7a8bad372e7402dda7f5e9df9a60e285b6f56d7  mig-1.5.tar.gz.sig

Please read the FAQ at http://www.gnu.org/software/hurd/faq.html.
Bug reports should be sent to bug-hurd@gnu.org or filed on
http://savannah.gnu.org/bugs/?group=hurd.  Requests for assistance
should be sent to help-h...@gnu.org or filed on
http://savannah.gnu.org/support/?group=hurd.  You can also find us on
the Freenode IRC network in the #hurd channel.


For the maintainers,
 Thomas


signature.asc
Description: PGP signature





Re: address/leak sanitizer, somebody?


2015-04-14

Thread
Thomas Schwinge

Hi!

On Tue, 14 Apr 2015 17:03:46 +0200, Samuel Thibault samuel.thiba...@gnu.org 
wrote:
 Samuel Thibault, le Tue 14 Apr 2015 15:08:51 +0200, a écrit :
  For work I've been having a look at -fsanitize in gcc.  It's not as
  powerful as valgrind, but it should provide very good feedback, and
  apart from tsan, it seems to be very easy to port to other systems
  (basically tell the ucontext layout, the rest is mostly glibc-generic
  actually), could somebody have a look?
 
 Apparently asan (address sanitizer) is 64bit only, but lsan (memory
 leak) seems to be 32bit too.

When I had a (really quick) look, years ago,
http://darnassus.sceen.net/~hurd-web/open_issues/_san/, I
found/declared that »[p]orting these to the Hurd is not a trivial task,
for they have intimate knowledge about the operating system kernel
they're running on, and from a first look they reimplement a lot of glibc
by directly using system calls -- which is basically a no-go on GNU
Hurd«.  Well, maybe not a no-go, but if my analysis is still correct,
we'd need to add a lot of wrapper code, to call back into the real libc
(instead of doing system calls).

That said, I'd be very happy about such a port, of course.  Preferably
this should be done directly upstream, that is, in the LLVM repository.
(Which will then be merged in GCC.)


Grüße,
 Thomas


signature.asc
Description: PGP signature





Re: Release process  rolling new releases


2015-04-09

Thread
Thomas Schwinge

Hi!

On Wed, 08 Apr 2015 00:35:17 +0200, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 Quoting Thomas Schwinge (2014-09-23 17:09:30)
  The (technical) release process is not the problem; that I can do any
  time.
 
 Awesome! Let's make one now.

:-) Will do tomorrow morning.

I know the NEWS files have been updated occasionally -- are they up to
date now?


Grüße,
 Thomas


signature.asc
Description: PGP signature




    
  1   2   3   4   5   6   7   8   9   10    >