Broken stack traces on crashed programs

Hello! I’ve noticed that I’d always get “broken” stack traces in GDB when (1) attaching to a program suspended by /servers/crash-suspend, (2) examining a core dump, or (3) spawning a program in GDB and examining it after it’s received an unhandled signal like SIGILL. At best I can see the backtra

Re: Broken stack traces on crashed programs

Hi! Samuel Thibault skribis: > Ludovic Courtès, le mar. 17 nov. 2020 10:57:43 +0100, a ecrit: >> I’ve noticed that I’d always get “broken” stack traces in GDB when (1) >> attaching to a program suspended by /servers/crash-suspend, (2) >> examining a core dump, or (3) spaw

Re: Broken stack traces on crashed programs

Hi, Samuel Thibault skribis: > Ludovic Courtès, le mar. 17 nov. 2020 14:55:32 +0100, a ecrit: >> Samuel Thibault skribis: >> >> > Ludovic Courtès, le mar. 17 nov. 2020 10:57:43 +0100, a ecrit: >> >> I’ve noticed that I’d always get “broken” stack traces

Re: Hurd Security vulnerabilities, please upgrade!

Hi Samuel, Samuel Thibault skribis: > Ricardo Wurmus, le mar. 10 août 2021 17:52:34 +0200, a ecrit: >> I’m a little unclear on what this means for distributions like Guix. Should >> we just update to the latest version from git? Are there specific commits >> we should use if it’s not just the

Kernel crash with rtl8139 while restarting pfinet

Hello! I stumbled upon a crash while running GNU/Hurd in QEMU with rtl8139 emulation along these lines: qemu-system-i386 -enable-kvm -m 1024 -hda /gnu/store/mkvai2a97w702yhayv66y62kd7r2j1ps-disk-image \ -snapshot "--device" "rtl8139,netdev=net0" --netdev user,id=net0 The crash is pretty r

Re: Kernel crash with rtl8139 while restarting pfinet

Hi, Samuel Thibault skribis: > Ludovic Courtès, le dim. 24 oct. 2021 15:47:36 +0200, a ecrit: >> $ addr2line -e >> /gnu/store/acl9ffg0pjcj1hvzf8f5pz98xm0cqpps-gnumach-1.8-1.097f9cf/boot/gnumach >> 0xc10b1f5d 0xc105c6da 0xc1046209 0xc1040d25 0xc104a7a5 0xc1022252 >

Re: [VULN 0/4] Hurd vulnerability details

Hello, Samuel Thibault skribis: > Thanks a lot for this writing! That'll surely be an interesting read for > whoever wants to look a bit at the details of how the Hurd works. And of > course thanks for finding and fixing the vulnerabilities :) Seconded. It’s interesting both from a security pe

Re: [VULN 0/4] Hurd vulnerability details

Hi Samuel, Sergey, & all, Samuel Thibault skribis: > Ludovic Courtès, le mar. 09 nov. 2021 18:19:03 +0100, a ecrit: >> Am I right that the fixes have not been applied yet in the upstream >> repository? > > That's right. That's still waiting for the copyright a

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hello! On AMD EPYC processors, as found on the build nodes of ci.guix.gnu.org, childhurd VMs fail to boot when running with ‘qemu-system-i386 -enable-kvm’ (the kvm-amd Linux kernel module is used), with the Hurd startup process hanging before /hurd/exec has been started: --8<---cut he

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi! As suggested by Samuel on IRC, I did that early on in kdb: debug traps /on such that it would stop on each trap, hopefully allowing me to see why exec is not starting. --8<---cut here---start->8--- module 0: ext2fs --multiboot-command-line=${kernel-comm

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Samuel Thibault skribis: > Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit: >> such that it would stop on each trap, hopefully allowing me to see why >> exec is not starting. > > Also, better use exec.static to have static addresses. Thanks for the hint.

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi! Samuel Thibault skribis: > Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit: [...] >> Of course, the thing boots just fine on that machine when using >> ‘exec.static’. > > Uh. At least you have a workaround :) Yup. :-) >> So the issue migh

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi Samuel, Samuel Thibault skribis: > About the backtrace: > >> user space < > 0x1000(bf24,0,0,1160b,0) > 0x11627(bf9c,0,0,0,2) > 0x11bb() > > That is quite surprising actually: in my ld.so there is nothing useful > at 0x1000. Perhaps you can check what 0x11627 is all about? Sur

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi! Ludovic Courtès skribis: > $ addr2line -e > /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1 > 0x1000 0x11627 0x11bb > ??:0 > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333 > :? > > > That’s

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Ludovic Courtès skribis: > Through a dichotomy I tried to see how far it goes. The info I have so > far is that ld.so errors out from elf/rtld.c:563 (line 565 is not > reached): > > 558: if (bootstrap_map.l_addr || ! > bootstrap_map.l_info[VALIDX(DT_GNU_PRELINKED)])

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi, Ludovic Courtès skribis: > … so ‘exec_load’ is doing its job, it seems. Turns out that may not be the case. Here’s a *bad* mapping on the second ‘task_resume’ breakpoint (when ‘exec’ is about to start): --8<---cut here---start->8--- db&

Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

Hi, Ludovic Courtès skribis: > Of course, the thing boots just fine on that machine when using > ‘exec.static’. It’s frustrating I did not get to the bottom of it, but time passes, so I pushed this workaround in Guix commit 3fb3bd3da530a5f82a169b1fa451474f9d90c3b6. Ludo’.

Apparent deadlock in processes interacting with /hurd/fifo

Hello, Let’s assume you do this: mkfifo fifo rpctrace cat fifo In another terminal, you find the PID of ‘cat’ and run “kill PID”, twice. The second ‘kill’ command hangs. The ‘cat’ process, which was initially stuck in dir_lookup("fifo"), eventually fails to service the second kill request

Re: Apparent deadlock in processes interacting with /hurd/fifo

Ludovic Courtès skribis: > I think there’s at least one bug here: ‘dir_lookup’ should complete > immediately; it’s ‘io_read’ that should block. This issue also breaks a Coreutils test: https://issues.guix.gnu.org/58803 Ludo’.

Re: coreutils-8.32 test failure on i586-gnu

Hi, Samuel Thibault skribis: > It seems that replying on the web interface didn't work, so replying > again here by mail. Weird. > Ludovic Courtès, le mer. 26 oct. 2022 19:20:07 +0200, a ecrit: >> ludo@childhurd ~$ mkfifo fifo >> ludo@childhurd ~$ ls -l fifo >&g

Re: Apparent deadlock in processes interacting with /hurd/fifo

Hi, Samuel Thibault skribis: > Ludovic Courtès, le ven. 25 nov. 2022 12:35:58 +0100, a ecrit: >> Let’s assume you do this: >> >> mkfifo fifo >> rpctrace cat fifo >> >> I think there’s at least one bug here: ‘dir_lookup’ should complete >>

Pushing a MiG release tarball?

Hello! Version 2.35 of glibc expects ‘const’-qualified parameters in MiG-generated stubs. Unfortunately, that feature is not is MiG 1.8, the latest release. Would you consider tagging a new release and uploading a tarball to ftp.gnu.org? The reason I’m asking is that Guix will need such a tarba

Re: [RFC PATCH 0/2] On ldconfig and ld.so.cache

Hi, Sergey Bugaev skribis: > On Fri, May 19, 2023 at 2:52 PM Carlos O'Donell wrote: >> Removing configuration options and making it simple to configure and use >> glibc is great >> goal. I think that ldconfig should always be enabled and I don't see a >> downside to making >> `use_ldconfig=ye

Re: Moving to git

Hello, Roland McGrath writes: > But AFAIK git-cvsimport alone is easy enough to get right. We converted Guile's CVS repo (where there were a number of branches, several of which were active) to Git several months ago. The first attempt used `git-cvsimport' and was a failure, because this tool

Re: Moving to git

Hi Thomas, Thomas Schwinge writes: > On Fri, Jan 16, 2009 at 07:20:01PM +0100, Ludovic Courtès wrote: >> We converted Guile's CVS repo (where there were a number of branches, >> several of which were active) to Git several months ago. The first >> attempt used

Re: Someone interested in writing a regression test suite for Hurd components?

Hello, Thomas Schwinge writes: > I guess that instead of starting to write shell scripts etc. for handling > all this, something like expect, , or DejaGnu, > , should instead be used for this > task, but I have no experience with the

[bug #28859] remove(3) fails to remove an empty directory

ervers Severity: 3 - Normal Priority: 5 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Ludovic Courtès Originator Email: l...@gnu.org Open/

[bug #28859] remove(3) fails to remove an empty directory

Follow-up Comment #2, bug #28859 (project hurd): I forwarded the bug to glibc's bug tracker: http://sources.redhat.com/bugzilla/show_bug.cgi?id=11276 . ___ Reply to this item at: __

[bug #28859] remove(3) fails to remove an empty directory

Follow-up Comment #3, bug #28859 (project hurd): For now, how about fixing it locally in hurd/glibc.git at Savannah? ___ Reply to this item at: ___ Me

Re: [bug #28859] remove(3) fails to remove an empty directory

Hi, Samuel Thibault writes: > Ludovic Courtès, le Tue 23 Feb 2010 16:40:12 +, a écrit : >> For now, how about fixing it locally in hurd/glibc.git at Savannah? > > For now, I've commited a fix to Debian's glibc. Thanks! (Though I don’t think it’s Debian-specific.) Ludo’.

Re: blubber and grubber down

Hi, Thomas Schwinge writes: > On Tue, Nov 10, 2009 at 05:47:24PM +0100, I wrote: >> On Sun, Nov 08, 2009 at 11:45:39AM +0100, I wrote: >> > I think I'll reinstall them later today (preserving /home/, of course). >> >> Sergiu rightfully so reminded me that I had forgotten to do that. >> blubber

Re: cross-gnu revived

Hello, Thomas Schwinge writes: > This is just to tell you that cross-gnu is back alive. See > . [...] > Seriously, there is a Grand Plan of evolving this into a complete > regression testing system: use these toolchains to b

$CRASHSERVER not honored?

Hi, In addition to , it seems that $CRASHSERVER isn’t honored, as suggested some time ago [0], or perhaps the observations below are a side effect of another problem: --8<---cut here---start->8---

$CRASHSERVER not honored?

Hi, In addition to , it seems that $CRASHSERVER isn’t honored, as suggested some time ago [0], or perhaps the observations below are a side effect of another problem: --8<---cut here---start->8---

Glibc cross-compilation error

Hello, Cross-compilation of glibc 2.11.1 from the official release tarball fails for me: --8<---cut here---start->8--- gawk -f ../scripts/gen-as-const.awk ../sysdeps/i386/tlsdesc.sym \ | i586-pc-gnu-gcc -S -o /tmp/nix-build-0r7cgavcrf4h2ng9cys44izxfc5x

Re: Glibc cross-compilation error

Hello Thomas! Thomas Schwinge writes: > On Wed, May 12, 2010 at 05:54:18PM +0200, Ludovic Courtès wrote: >> Cross-compilation of glibc 2.11.1 from the official release tarball >> fails for me: > > According to your failure log, you're building this in an Nix > envir

‘make dist’ fails in hurd/glibc.git

Hello, ‘make dist’ in hurd/glibc.git (the right branch, whatever it’s called) fails: --8<---cut here---start->8--- fatal: No names found, cannot describe anything. make[1]: *** [dist] Error 1 --8<---cut here---end--->8--- In

Cross-GNU toolchain in Nixpkgs

Hello! With the Nix package manager [0], one can now use the cross-GNU toolchain available in Nixpkgs [1] to cross-build packages from GNU/Linux to GNU. It uses GCC 4.5.0 and recent Hurd/Mach snapshots. With Nix each package is installed in a prefix of its own, which led to interesting problems

Continuous Hurd cross-builds on Hydra

Hello! The GNU Hurd is now continuously cross-built on Hydra from GNU/Linux: http://hydra.nixos.org/jobset/gnu/hurd-master There are 3 ‘jobs’ there: - The ‘tarball’ job, which does “make dist”. - The ‘xbuild’ job, which cross-builds off the tarball. - The ‘xbootstrap’ job, which does

Continuous Hurd cross-builds on Hydra

Hello! The GNU Hurd is now continuously cross-built on Hydra from GNU/Linux: http://hydra.nixos.org/jobset/gnu/hurd-master There are 3 ‘jobs’ there: - The ‘tarball’ job, which does “make dist”. - The ‘xbuild’ job, which cross-builds off the tarball. - The ‘xbootstrap’ job, which does

Re: Continuous Hurd cross-builds on Hydra

Hi Olaf, writes: >> Hydra can send email notifications when the status of a build changes >> (e.g., from ???succeeded??? to ???failed???.) I can add whoever feels >> like receiving Hydra news. > > Well, if it doesn't generate a lot of traffic, you could probably just > make it send that stuff t

GNU Mach: MIG stubs not generated

Hello, GNU Mach currently fails to build for me: --8<---cut here---start->8--- i586-pc-gnu-gcc -DHAVE_CONFIG_H -I. -nostdinc -imacros config.h -Ii386 -I. -I./i386 -I./i386/include/mach/sa -I./include -Wall -fno-strict-aliasing -fno-stack-protector -g -O2 -c

Re: GNU Mach: MIG stubs not generated

Hi! Thomas Schwinge writes: > On Wed, May 26, 2010 at 02:07:09PM +0200, Ludovic Courtès wrote: >> GNU Mach currently fails to build for me: >> >> --8<---cut here---start->8--- >> i586-pc-gnu-gcc -DHAVE_CONFIG_H -I. -nos

Re: ‘make dist’ fails in hurd/glibc.git

Hi Thomas, Thomas Schwinge writes: > Hello! > > On Fri, May 21, 2010 at 09:37:42AM +0200, Ludovic Courtès wrote: >> ‘make dist’ in hurd/glibc.git (the right branch, whatever it’s called) >> fails: >> >> --8<---cut here---start---

Re: Continuous Hurd cross-builds on Hydra

Hi, writes: > Well, in X.Org the person running the tinderbox is also the one checking > the results; and he sends mails to the developer list whenever the > results indicate that a new commit broke something. I may report problems occasionally but I essentially view it as a service for Hurd ha

Re: Hurd hackers at GNU Hackers Meeting?

Hello, Tibi Turbureanu writes: > Is there any chance I could meet any of you Hurd hackers this July at > GHM 2010, Hague? :-) There’s one Hurd hacker listed at . I don’t qualify as a Hurd hacker but we could certainly discuss Hurd things. ;-) Ludo’.

Re: Usable translators

Hello, I *think* tarfs is usable too, though I haven’t checked in years. Thanks, Ludo’.

Re: Usable translators

Hi, Arne Babenhauserheide writes: > On Saturday 10 July 2010 16:53:59 Ludovic Courtès wrote: >> I *think* tarfs is usable too, though I haven’t checked in years. > > I assume it shows a tarfile. Am I right? Yes: <http://hurdextras.nongnu.org/#tarfs>. Thanks, Ludo’.

Re: What can a translator do that FUSE can’t?

Hi, Roland McGrath writes: > It's all just software. You can encode your interfaces any way you want. Unlike the Hurd, Plan 9 exposes everything textually (through a file system interface), but that is sometimes awkward (the ‘ctl’ files...) and the marshalling/unmarshalling is probably ineffic

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

Hi, Emilio Pozuelo Monfort writes: > error_t > S_socket_getopt (struct sock_user *user, >int level, int opt, >char **value, size_t *value_len) > { > - return EOPNOTSUPP; > + int ret = 0; > + > + if (!user) > +return EOPNOTSUPP; > + > + mutex_lock (&user

[PATCH 1/9] Fix "make dist" in `console-client'

Hello! This is the first of a series of 9 patches that fix “make dist” in the Hurd, and which have been used in continuous builds on Hydra [0]. Most of them are trivial, and the last one may be slightly controversial. The nice thing is that once “make dist” works, there’s little that prevents yo

[PATCH 7/9] Fix "make dist" in `sutils'

From 496924b22c4e896d50b5b45b533c92882399944a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Sat, 17 Jul 2010 16:07:47 +0200 Subject: [PATCH 7/9] Fix "make dist" in `sutils'. * sutils/Makefile (SRCS): Add `clookup.c', `fstab.c', and `update.c'. --- sutils/Makefile |4

[PATCH 3/9] Fix "make dist" in `exec'

From 55754cad6f51e753577d9d620fe40c4f958bf0de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Sat, 17 Jul 2010 15:57:42 +0200 Subject: [PATCH 3/9] Fix "make dist" in `exec'. * exec/Makefile (SRCS): Refer to `$(gzip-sources)' and `$(bzip2-sources)' instead of listing file

[PATCH 8/9] Fix "make dist" in `pfinet'

This patch isn’t perfect in that stale ‘.o’ files or similar in the ‘linux-src’ and ‘glue-include’ directories would end up in the tarball. However, doing it the Right Way is somewhat tedious, so I consider this patch OK as a first approach. Thoughts? Thanks, Ludo’. From f0bcfbf475831c16a8416c34

[PATCH 5/9] Fix "make dist" in `libcons'

From a3a336d5fa94d1f856ffdc0e8c45b7db455578b2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Sat, 17 Jul 2010 16:00:16 +0200 Subject: [PATCH 5/9] Fix "make dist" in `libcons'. * libcons/Makefile (LCLHDRS): Add `$(installhdrs)'. --- libcons/Makefile |4 ++-- 1 files c

[PATCH 2/9] Fix "make dist" in `daemons'

From b02ceb3e85a9e98374d919a2d1995a7388926175 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Sat, 17 Jul 2010 15:54:56 +0200 Subject: [PATCH 2/9] Fix "make dist" in `daemons'. * daemons/Makefile (SRCS): Add `runsystem.sh'. --- daemons/Makefile |4 ++-- 1 files change

[PATCH 6/9] Fix "make dist" in `libthreads'

From 8274c9e197f7d9edb44c0e22ab2cf7f1d83cbeff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Sat, 17 Jul 2010 16:01:52 +0200 Subject: [PATCH 6/9] Fix "make dist" in `libthreads'. * libthreads/Makefile (lndist, lndist-map-file): New targets. Link `libthreads.map' to the

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

Hi, Carl Fredrik Hammar writes: > On Sat, Jul 17, 2010 at 03:36:43PM +0200, Ludovic Courtès wrote: >> Emilio Pozuelo Monfort writes: >> >> > error_t >> > S_socket_getopt (struct sock_user *user, >> > int level, int opt, >&g

[PATCH 4/9] Fix "make dist" in `include'

From 50968edf6a4ee8af6ff63e2ee4a5b4d97013ff3d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= Date: Sat, 17 Jul 2010 15:59:25 +0200 Subject: [PATCH 4/9] Fix "make dist" in `include'. * include/Makefile (lndist): New target. Copy `Makefile' and `$(installhdrs)' to the distribu

Re: GPL code reuse questions

Hi, Svante Signell writes: > According to my findings Hurd is licensed as GPL v2 only No, it’s GPLv2+, as can be seen from the source file headers. Thanks, Ludo’.

Re: [PATCH 8/9] Fix "make dist" in `pfinet'

Hi! Samuel Thibault writes: > Ludovic Courtès, le Sat 17 Jul 2010 16:44:08 +0200, a écrit : >> This patch isn’t perfect in that stale ‘.o’ files or similar in the >> ‘linux-src’ and ‘glue-include’ directories would end up in the tarball. >> However, doing it the Right Wa

Cross-builds on Hydra now with Parted

Hello! Starting from today, Hydra continuously cross-builds the Hurd [0] against a fresh checkout of GNU Parted, which should make it easy to spot any incompatibilities introduced between the two. Build results are accessible at: http://hydra.nixos.org/jobset/gnu/hurd-master Thanks, Ludo’. [

Re: Moved some packages

Hi! Thomas Schwinge writes: > Some packages have been moved / promoted ;-) from hurdextras to the > Hurd's incubator repository: Woow! ;-) > * tarfs (Ludovic Courtès): tarfs/master > <http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=tarfs/master> FWIW

Re: [PATCH 4/4] Fix 'make dist' in mach-defpager

Hello! Diego Martin Nieto Cid writes: > From: Diego Nieto Cid > > * mach-defpager/Makefile (SRCS): Remove external sources > default_pager.c, kalloc.c and wiring.c. > (OBJS): Add objects for external sources. Corresponding > source files will be found in vpath. Did you see this proposal? ht

Exporting libc patches

Hello! I’m looking at how to export patches from the ‘tschwinge/Roger_Whittaker’ branch to continuously test on Hydra whether they still apply to upstream glibc. To that end, the idea I had was to do something along these lines: git checkout tschwinge/Roger_Whittaker tg export --linearize

Re: [PATCH 9/9] Remove `serverboot'; fix "make dist" in `mach-defpager'

Hello! l...@gnu.org (Ludovic Courtès) writes: > This is the potentially controversial patch. :-) > > It removes serverboot, which is no longer built since commit > dfa4d617a012dd46d3849e0d2538a4b7890c1306 (Sept. 2004), and moves the > files that are actually used by ‘mach-def

Re: [PATCH 9/9] Remove `serverboot'; fix "make dist" in `mach-defpager'

Hello! I can confirm that ‘make dist’ works like a charm: http://hydra.nixos.org/job/gnu/hurd-master/tarball The latest tarball can be obtained from: http://hydra.nixos.org/job/gnu/hurd-master/tarball/latest Thanks, Ludo’.

Re: Exporting libc patches

Hi! (I hear there’s a deadline approaching, so trying to see how I could do something useful. ;-)) l...@gnu.org (Ludovic Courtès) skribas: > I’m looking at how to export patches from the > ‘tschwinge/Roger_Whittaker’ branch to continuously test on Hydra whether > they still apply to

Re: Exporting libc patches

Samuel Thibault skribis: > Ludovic Courtès, le Mon 06 Jun 2011 14:39:39 +0200, a écrit : >> @@ -79,6 +79,8 @@ >> extern int __dup (int __fd); >> extern int __dup2 (int __fd, int __fd2); >> libc_hidden_proto (__dup2) >> +extern int __dup3

Re: GNU Free Call GUI, ``Discover Hurd''

Hi, Thomas Schwinge skribis: > On , is > ``Discover Hurd'' meant to reference the GNU Hurd project, or is it > something else? My impression is that the GUI mocks should read “gnu” instead of “GNU” and “herd” instead of “Hurd”. Thanks, L

Re: Exporting libc patches

Hello! Samuel Thibault skribis: > Ludovic Courtès, le Mon 06 Jun 2011 14:39:39 +0200, a écrit : >> @@ -79,6 +79,8 @@ >> extern int __dup (int __fd); >> extern int __dup2 (int __fd, int __fd2); >> libc_hidden_proto (__dup2) >> +extern int __dup3

[bug #33566] Hurd fails to (cross-)build with `-O0'

URL: Summary: Hurd fails to (cross-)build with `-O0' Project: The GNU Hurd Submitted by: civodul Submitted on: Tue 14 Jun 2011 08:49:06 PM GMT Category: glibc Severity:

Re: Exporting libc patches

Hi, l...@gnu.org (Ludovic Courtès) skribis: > Samuel Thibault skribis: > >> Ludovic Courtès, le Mon 06 Jun 2011 14:39:39 +0200, a écrit : >>> @@ -79,6 +79,8 @@ >>> extern int __dup (int __fd); >>> extern int __dup2 (int __fd, int __fd2); >>> l

Re: git clone fails

Hello, Florian Friesdorf skribis: > url taken from: > http://git.savannah.gnu.org/cgit/hurd/glibc.git > > $ git clone git://git.sv.gnu.org/hurd/glibc.git > Cloning into glibc... > remote: Counting objects: 250057, done. > remote: Compressing objects: 100% (39390/39390), done. > remote: Total 250

Re: Released the QotH 2011-q2 to the wiki: please proofread!

Arne Babenhauserheide skribis: > At Fri, 01 Jul 2011 11:33:37 +0200, > Svante Signell wrote: >> >> Change freekbsd to kFreeBSD, I think that is the official abbreviation. > > Fixed, thanks! The OS name is GNU/kFreeBSD, though. Ludo’.

[HURD, PATCH] Fix stack switching at initialization time

iff --git a/ChangeLog b/ChangeLog index 606bc22..6239986 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2011-07-22 Ludovic Courtès + + * sysdeps/mach/hurd/i386/init-first.c (init): Use + `__builtin_return_address' and `__builtin_frame_address' instead + of making assumptions about

Re: [HURD, PATCH] Fix stack switching at initialization time

Hi! Thomas Schwinge skribis: > This patch is to be put on top of our TopGit t/init-first.c branch, I > guess, which itself is not yet in the sourceware repository, I think? Right, other changes in t/init-first.c aren’t in the Sourceware repo. Here’s the diff between the Savannah + this patch an

Re: [HURD, PATCH] Fix stack switching at initialization time

Hi, Thomas Schwinge skribis: > This patch is to be put on top of our TopGit t/init-first.c branch, I > guess, which itself is not yet in the sourceware repository, I think? Pushed a slightly different version, thanks! http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=t/init-first.c&id=

[bug #33850] Loader crashes when used with `LD_DEBUG=files'

URL: Summary: Loader crashes when used with `LD_DEBUG=files' Project: The GNU Hurd Submitted by: civodul Submitted on: Sun 24 Jul 2011 10:23:43 PM GMT Category: glibc S

Libc patch no longer applies

Hi, The libc patch from Savannah’s repo no longer applies to upstream libc [0]. This is a consequence of the removal of lack-of-TLS support: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d063d164335938d557460bebaa7cfe388157b627;hp=3ce1f2959437e952b9db4eaeed2407424f11a4d1 Should we reb

Re: Libc patch no longer applies

Thomas Schwinge skribis: > On Tue, 13 Sep 2011 10:46:01 +0200, l...@gnu.org (Ludovic > =?iso-8859-1?Q?Court=E8s?=) wrote: >> Should we rebase Savannah’s libc on top of the current upstream libc and >> then update the topic branches accordingly? > > Yes, and I'm AT THE MOMENT :-) working towards

Re: [HURD, PATCH] Fix stack switching at initialization time

Hi, Thomas Schwinge skribis: > On Fri, 22 Jul 2011 17:53:12 +0200, l...@gnu.org wrote: >> Pushed a slightly different version, thanks! >> >> http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=t/init-first.c&id=53b56b1101fc9bb4f295f23f54e7e19f8da8da16 > > Just a heads-up, and I'm afraid,

Re: Libc patch no longer applies

Hi Thomas! Thomas Schwinge skribis: > ... and this did work! That is, ``--build=i486-gnu --host=i486-gnu'' > configuration with GCC 4.4, plus old binutils downgraded to Debian > package 2.20.1-2. > > And, on the other machine (with the 2010-04 trees), I built with recent > binutils as a crossch

Re: Libc patch no longer applies

Hi Thomas, Thomas Schwinge skribis: > This 00-glibc-hurd.patch seems to be bogus. How exactly do you create > it? >From : # Do a raw diff against this `baseline' commit. git diff ea42a20caed5b343ff20a0d4622ae6c17b7716

Re: Exporting libc patches

Hi Thomas, Thomas Schwinge skribis: > On Wed, 23 Mar 2011 14:30:17 +0100, l...@gnu.org (Ludovic > =?iso-8859-1?Q?Court=E8s?=) wrote: [...] >> A further complication is that ‘tg remote --populate’ did not fetch the >> ‘baseline’ branch, which is consequently reported as a missing >> dependency

Re: Exporting libc patches

Hi Thomas, Thomas Schwinge skribis: > On Sun, 16 Oct 2011 21:35:29 +0200, l...@gnu.org (Ludovic > =?iso-8859-1?Q?Court=E8s?=) wrote: >> In the meantime I’ve changed the commit SHA1 [0], and it does lead to a > >> [0] >> http://git.savannah.gnu.org/cgit/hydra-recipes.git/commit/?id=7f49a0c373af

Re: Exporting libc patches

Hi Thomas, Thomas Schwinge skribis: > On Thu, 13 Oct 2011 17:16:59 +0200, I wrote: >> On Wed, 23 Mar 2011 14:30:17 +0100, l...@gnu.org (Ludovic >> =?iso-8859-1?Q?Court=E8s?=) wrote: >> > A further complication is that ‘tg remote --populate’ did not fetch the >> > ‘baseline’ branch, which is con

Re: Exporting libc patches

Howdy! Thomas Schwinge skribis: > On Sat, 29 Oct 2011 15:39:00 +0200, l...@gnu.org (Ludovic > =?iso-8859-1?Q?Court=E8s?=) wrote: [...] >> Besides, the part of the Savannah patch that touches >> sysdeps/i386/configure fails to apply to Sourceware’s glibc >> (unsurprisingly):

libc & libpthread circular dependency

Hello, It used to be that Savannah’s libc could be compiled without libpthread, because none of the source files would explicitly include . This is no longer the case with the recent changes where the new nss_files/files-init.c includes (so it can use struct traced_file), which includes and use

Re: libc & libpthread circular dependency

Hi Thomas, Thomas Schwinge skribis: > Here is what I'm doing in cross-gnu; simply install the libpthread > headers before building glibc: > . Indeed. I’ve done the same i

[PATCH] Disable NFS translator & daemon when Sun RPC support is missing

Hello, The patch below disables building of the NFS translator and daemon when Sun/ONC RPC support is missing, as is the case with GNU libc 2.14+, and until TI-RPC actually is actually buildable on GNU. OK to apply? Thanks, Ludo’. diff --git a/Makefile b/Makefile index ad187d0..e0ba052 100644 -

Re: [PATCH] Disable NFS translator & daemon when Sun RPC support is missing

Hi Thomas, Thanks for the quick reply. Thomas Schwinge skribis: > On Thu, 03 Nov 2011 23:12:52 +0100, l...@gnu.org (Ludovic > =?iso-8859-1?Q?Court=E8s?=) wrote: >> The patch below disables building of the NFS translator and daemon when >> Sun/ONC RPC support is missing, as is the case with GNU

[PATCH] mach-defpager: Declare `__malloc_initialize_hook' as volatile

Hello, Mach-defpager uses libc’s malloc hooks and fails to build with libc 2.14 where they are declared as volatile [0]: --8<---cut here---start->8--- i586-pc-gnu-gcc -std=gnu99 -fgnu89-inline -g -O3 -g -O2 -I. -I.. -I../include -I../include -D_GNU_SOURCE -D

Re: [PATCH] mach-defpager: Declare `__malloc_initialize_hook' as volatile

Thanks, done. The Hurd now builds with Savannah’s libc (2.14+). Ludo’.

[PATCH] Allow /hurd/init to be a symlink

Hello! The attached patch allows /hurd or /hurd/init to be a symlink to an absolute path. OK to apply? Thanks, Ludo’. diff --git a/libdiskfs/boot-start.c b/libdiskfs/boot-start.c index e73e4d3..30b54d3 100644 --- a/libdiskfs/boot-start.c +++ b/libdiskfs/boot-start.c @@ -1,5 +1,5 @@ /* - Copy

Re: [PATCH] Allow /hurd/init to be a symlink

Hi, Samuel Thibault skribis: > Ludovic Courtès, le Mon 07 Nov 2011 21:35:06 +0100, a écrit : >> + lookup_init: >>err = dir_lookup (root_pt, initname, O_READ, 0, >> &retry, pathbuf, &startup_pt); >>if (err) >> @@ -232,6 +233,13 @@

[PATCH] Provide modern Autoconf initialization

Hello, OK to apply? :-) Ludo’. diff --git a/configure.in b/configure.in index 635242d..05b959b 100644 --- a/configure.in +++ b/configure.in @@ -1,7 +1,7 @@ dnl Process this file with autoconf to produce a configure script. AC_REVISION([$Id: configure.in,v 1.38 2008/11/17 11:34:18 tschwinge Ex

[PATCH] Have `rc' and `runsystem' use /bin/sh

Hello, These two scripts really need a plain POSIX shell, not necessarily Bash. This patch changes the shebang accordingly. (Tested with Bash 4.1 run as /bin/sh.) OK? Ludo’. diff --git a/daemons/rc.sh b/daemons/rc.sh index 5778094..e9f7fca 100644 --- a/daemons/rc.sh +++ b/daemons/rc.sh @@ -1,

A tale of bootstrap ld.so debugging

Hello! While cross-building a GNU/Hurd QEMU image, I stumbled upon a series of bugs, the last one of which led to a one-liner adding libgcc_s.so to the image. Lack of libgcc_s.so prevented the initial /hurd/exec to run. The kernel debugger showed a backtrace in ld.so hinting at an undefined symb

Re: [PATCH] Have `rc' and `runsystem' use /bin/sh

Samuel Thibault skribis: > Ludovic Courtès, le Mon 07 Nov 2011 22:43:22 +0100, a écrit : >> These two scripts really need a plain POSIX shell, not necessarily >> Bash. This patch changes the shebang accordingly. > > Mmm, are "local" and functions really in P

  1   2   3   4   >