Re: [RFC PATCH 11/23] hurd: Initializy _dl_pagesize early in static builds

Applied, thanks! Sergey Bugaev, le mer. 03 janv. 2024 20:14:44 +0300, a ecrit: > We fetch __vm_page_size as the very first RPC that we do, inside > __mach_init (). Propagate that to _dl_pagesize ASAP after that, > before any other initialization. > > In dynamic builds, this

[RFC PATCH 11/23] hurd: Initializy _dl_pagesize early in static builds

We fetch __vm_page_size as the very first RPC that we do, inside __mach_init (). Propagate that to _dl_pagesize ASAP after that, before any other initialization. In dynamic builds, this is already done immediately after __mach_init (), inside _dl_sysdep_start (). Signed-off-by: Sergey Bugaev

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Hello, Sergey Bugaev via Libc-alpha, le ven. 14 avril 2023 11:53:43 +0300, a ecrit: > - /* Make sure we have a valid reply port. The one we were using > -may have been destroyed by interruption. */ > - m->header.msgh_local_port = rcv_name = __mig_get_reply_port (); >

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Fri, Apr 14, 2023 at 8:34 PM Samuel Thibault wrote: > Reapplied on top of "Remove __hurd_local_reply_port", thanks! Awesome, thank you! I have implemented the changes we talked about (replacing the receive right with a dead name...), and they even seem to pass the few tests from the testsuite

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Reapplied on top of "Remove __hurd_local_reply_port", thanks! Sergey Bugaev, le dim. 19 mars 2023 18:10:07 +0300, a ecrit: > When glibc is built as a shared library, TLS is always initialized by > the call of TLS_INIT_TP () macro made inside the dynamic loader, prior > to running the main program

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev via Libc-alpha, le ven. 14 avril 2023 12:23:00 +0300, a ecrit: > On Fri, Apr 14, 2023 at 12:12 PM Samuel Thibault > wrote: > > Sergey Bugaev via Libc-alpha, le ven. 14 avril 2023 11:53:43 +0300, a ecrit: > > > It's in _hurdsig_abort_rpcs, if the interrupt_operation call fails. > > >

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Fri, Apr 14, 2023 at 12:12 PM Samuel Thibault wrote: > Sergey Bugaev via Libc-alpha, le ven. 14 avril 2023 11:53:43 +0300, a ecrit: > > It's in _hurdsig_abort_rpcs, if the interrupt_operation call fails. > > > > Let's maybe not do that either? We're already making mach_msg seem to > > have retu

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev via Libc-alpha, le ven. 14 avril 2023 11:53:43 +0300, a ecrit: > It's in _hurdsig_abort_rpcs, if the interrupt_operation call fails. > > Let's maybe not do that either? We're already making mach_msg seem to > have returned EINTR, which intr-msg knows how to handle. Mmm, yes, but we

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Fri, Apr 14, 2023 at 11:39 AM Samuel Thibault wrote: > Sergey Bugaev, le ven. 14 avril 2023 11:29:37 +0300, a ecrit: > > But secondly, if we are not destroying the user's reply port, but > > restoring it, then I don't think the "port = MACH_PORT_NULL, arg = > > stale name" case can happen? So w

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev, le ven. 14 avril 2023 11:29:37 +0300, a ecrit: > But secondly, if we are not destroying the user's reply port, but > restoring it, then I don't think the "port = MACH_PORT_NULL, arg = > stale name" case can happen? So we don't need to handle it? > > We should really just assert (arg

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Fri, Apr 14, 2023 at 12:47 AM Samuel Thibault wrote: > #10 0x0106bc20 in __libc_assert_fail (assertion=0x1222762 "port == arg", > file=0x121c2a0 "../sysdeps/mach/hurd/mig-reply.c", line=92, > function=0x121c2c4 <__PRETTY_FUNCTION__.0> "__mig_dealloc_reply_port") > at __libc_assert_f

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Samuel Thibault, le jeu. 13 avril 2023 23:47:38 +0200, a ecrit: > Sergey Bugaev, le jeu. 13 avril 2023 15:17:51 +0300, a ecrit: > > I have now sent the second version of > > that patch, please try applying it and test if that fixes it. > > I'll give it a try. The first tests seem to be passing, I

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Hello, Sergey Bugaev, le jeu. 13 avril 2023 15:17:51 +0300, a ecrit: > I have now sent the second version of > that patch, please try applying it and test if that fixes it. I'll give it a try. > Please also check if the other reply port tweak you reverted today is > also innocent. The same test

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

de THREAD_SELF (and friends) work through __seg_gs, triggering the miscompilation. I'm surprised your testing hasn't caught it earlier, but maybe the extra branch/indirection for the no-tls case was masking the miscompilation. Please also check if the other reply port tweak you reverted

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev via Libc-alpha, le jeu. 13 avril 2023 13:02:58 +0300, a ecrit: > this is our very own thread port, the result of mach_thread_self () > which was called just several moments ago in hurd_self_sigstate ()! IIRC this is cached inside glibc... in a TLS variable probably. And thus if that

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Wow, this is great, thank you! You've really gone above and beyond compared to what I expected you to do. Some replies below; will reply to other points later. On Thu, Apr 13, 2023 at 2:47 AM Samuel Thibault wrote: > > Maybe you're building with some flags that affect this? I'm only doing > > ..

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev, le mer. 12 avril 2023 13:42:50 +0300, a ecrit: > before my SSH / network stack died were: (Gmail is surely going to > wrap this, but hopefully not too badly) > > gcc > /home/sergey/glibc/build/elf/dso-sort-tests-src/tst-dso-ordering9_42-bdeca-c.c > -c -std=gnu11 -fgnu89-inline -g

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Wed, Apr 12, 2023 at 1:45 PM Samuel Thibault wrote: > > Sergey Bugaev, le mer. 12 avril 2023 13:42:50 +0300, a ecrit: > > > You can run on master to get the list of current expected failures. > > > > But that's the thing, I can not :| > > I meant after having fixed the tests that break your tes

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev, le mer. 12 avril 2023 13:42:50 +0300, a ecrit: > > You can run on master to get the list of current expected failures. > > But that's the thing, I can not :| I meant after having fixed the tests that break your testing, by disabling them as I hinted. Samuel

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Wed, Apr 12, 2023 at 12:00 PM Samuel Thibault wrote: > Was that tst-spawn6? I can't point out any specific one :( There is just this huge wall of output, and then the whole thing breaks / hangs. FWIW, the last lines before my SSH / network stack died were: (Gmail is surely going to wrap this,

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev, le mer. 12 avril 2023 11:36:58 +0300, a ecrit: > Alright, this went much as expected. First it took an eternity to > compile (SMP support can't come soon enough), and second, the testuite > has brought the system into a bad state and didn't complete. In > particular: it managed to te

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Wed, Apr 12, 2023 at 12:23 AM Samuel Thibault wrote:> > Sergey Bugaev, le mar. 11 avril 2023 23:27:35 +0300, a ecrit: > > On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault > > wrote: > > > Had you actually tested it on i386? It seems to be breaking the > > > testsuite completely. I would expect

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Sergey Bugaev, le mar. 11 avril 2023 23:27:35 +0300, a ecrit: > On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault > wrote: > > Had you actually tested it on i386? It seems to be breaking the > > testsuite completely. I would expect that a submitted patch series has > > gone through the testsuite. >

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault wrote: > > Hello, > > Had you actually tested it on i386? It seems to be breaking the > testsuite completely. I would expect that a submitted patch series has > gone through the testsuite. Ouch! I have tested that it works on i386, as in I was able

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

I have reverted that change for now, so we get back to a working glibc. Samuel Samuel Thibault, le mar. 11 avril 2023 20:57:05 +0200, a ecrit: > Hello, > > Had you actually tested it on i386? It seems to be breaking the > testsuite completely. I would expect that a submitted patch series has > g

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Samuel Thibault, le mar. 11 avril 2023 20:57:05 +0200, a ecrit: > Had you actually tested it on i386? It seems to be breaking the > testsuite completely. I would expect that a submitted patch series has > gone through the testsuite. > > Sergey Bugaev, le dim. 19 mars 2023 18:10:07 +0300, a ecrit:

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Hello, Had you actually tested it on i386? It seems to be breaking the testsuite completely. I would expect that a submitted patch series has gone through the testsuite. Sergey Bugaev, le dim. 19 mars 2023 18:10:07 +0300, a ecrit: > When glibc is built as a shared library, TLS is always initializ

Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

Applied, thanks! Sergey Bugaev, le dim. 19 mars 2023 18:10:07 +0300, a ecrit: > When glibc is built as a shared library, TLS is always initialized by > the call of TLS_INIT_TP () macro made inside the dynamic loader, prior > to running the main program (see dl-call_tls_init_tp.h). We can take > ad

[RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

When glibc is built as a shared library, TLS is always initialized by the call of TLS_INIT_TP () macro made inside the dynamic loader, prior to running the main program (see dl-call_tls_init_tp.h). We can take advantage of this: we know for sure that __LIBC_NO_TLS () will evaluate to 0 in all other

Re: [PATCH 12/15] fix warnings for 32 bit builds

Il 27/08/22 21:17, Samuel Thibault ha scritto: Partially applied, thanks! Luca Dariz, le mar. 28 juin 2022 12:10:51 +0200, a ecrit: diff --git a/i386/i386at/biosmem.c b/i386/i386at/biosmem.c index 78e7bb21..fafdc048 100644 --- a/i386/i386at/biosmem.c +++ b/i386/i386at/biosmem.c @@ -29,8 +29,6 @

Re: [PATCH 12/15] fix warnings for 32 bit builds

Partially applied, thanks! Luca Dariz, le mar. 28 juin 2022 12:10:51 +0200, a ecrit: > diff --git a/i386/i386at/biosmem.c b/i386/i386at/biosmem.c > index 78e7bb21..fafdc048 100644 > --- a/i386/i386at/biosmem.c > +++ b/i386/i386at/biosmem.c > @@ -29,8 +29,6 @@ > #include > #include > > -#defi

[PATCH 12/15] fix warnings for 32 bit builds

Signed-off-by: Luca Dariz --- device/cirbuf.c| 4 ++-- i386/i386/debug_i386.c | 1 + i386/i386at/biosmem.c | 2 -- i386/i386at/com.c | 2 +- i386/i386at/mem.c | 1 + kern/boot_script.c | 1 + kern/bootstrap.h | 5 - kern/exception.c | 1 + vm/vm_debug.c

Re: Recent libc breaks Hurd builds

Svante Signell, le Sat 07 Mar 2015 19:39:13 +0100, a écrit : > On Sat, 2015-03-07 at 17:33 +0100, Justus Winter wrote: > > with the current libc from debian-ports (2.19-16~1) I see: > > > > gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -g -O2 -fstack-protector-strong > > -Wformat -Werror=format-sec

Re: Recent libc breaks Hurd builds

On Sat, 2015-03-07 at 17:33 +0100, Justus Winter wrote: > Hello, > > with the current libc from debian-ports (2.19-16~1) I see: > > gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -g -O2 -fstack-protector-strong > -Wformat -Werror=format-security -I. -I../../libshouldbeinlibc -I.. -I../.. > -I../in

Recent libc breaks Hurd builds

Hello, with the current libc from debian-ports (2.19-16~1) I see: gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -I. -I../../libshouldbeinlibc -I.. -I../.. -I../include -I../../include -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BI

Re: innocent-looking patch that breaks oot-builds

>>>>> Justus Winter <4win...@informatik.uni-hamburg.de> writes: > Hi, here is the innocent-looking patch that breaks out of tree > builds. Specifically? Could you please provide some excerpts of the build logs, highlighting the failure? >

innocent-looking patch that breaks oot-builds

Hi, here is the innocent-looking patch that breaks out of tree builds. Any thoughts how to fix this? Justus

Re: [PATCH 02/17] Enable silent builds by default if available

On Thu, 2011-08-25 at 09:46:00 -0700, Roland McGrath wrote: > So-called "silent" builds are a pox upon debuggability and should never be > the default. I agree silent rules should never be enabled for automated builds, for example on the Debian packaging, because that makes the b

Re: [PATCH 02/17] Enable silent builds by default if available

So-called "silent" builds are a pox upon debuggability and should never be the default.

[PATCH 02/17] Enable silent builds by default if available

* configure.ac (AM_SILENT_RULES): Add silent rules support if available, and enable it by default. * Makefile.am (AWK_V, AWK_V_, AWK_V_0): New variables. (NM_V, NM_V_, NM_V_0): Likewise. (GZIP_V, GZIP_V_, GZIP_V_0): Likewise. (MIGCOM_V, MIGCOM_V_, MIGCOM_V_0): Likewise. (gnumach-undef): Use NM_V in

[PATCH 3 of 3] builds again with cython 0.14.1

# HG changeset patch # User Arne Babenhauserheide # Date 1302228745 0 # Node ID d4979bcd090e7492806f77f5c0d62e4ceb365aee # Parent a91a6eb7e986103fae30942c76fa910973b4de22 builds again with cython 0.14.1 diff --git a/pyhurd/_hurd.pxd b/pyhurd/_hurd.pxd --- a/pyhurd/_hurd.pxd +++ b/pyhurd

Re: Cross-builds on Hydra now with Parted

Hi Ludovic, On Wednesday 25 August 2010 17:59:14 Ludovic Courtès wrote: > 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. Many thanks for s

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: 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: Continuous Hurd cross-builds on Hydra

Hi, On Wed, May 26, 2010 at 02:10:20PM +0200, Ludovic Courtès wrote: > 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 genera

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

Re: Continuous Hurd cross-builds on Hydra

Hi, On Mon, May 24, 2010 at 02:40:13PM +0200, Ludovic Courtès wrote: > Getting ???make dist??? to work was surprisingly tedious, presumably > because the project has a long tradition of not publishing source > releases. ;-) There???s a series of patches at >

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

Hi, On Wed, Dec 23, 2009 at 08:45:30PM +0100, Jakub Daniel wrote: > i should have asked whether there is an easy way how to make a new > disc image build myself (not to wait for L2, as i dont know how long > it would take to release L2). No, there is no *easy* way unfortunately. A couple of mont

Re: Builds

> Which repositories? > > In principle, Debian packages already follow the Hurd repositories well. > > Actually any official repositories.. i should have asked whether there is an easy way how to make a new disc image build myself (not to wait for L2, as i dont know how long it would take to releas

Re: Builds

Jakub Daniel, le Wed 23 Dec 2009 18:31:29 +0100, a écrit : > is it possible to build Hurd disc images from git repositories? Which repositories? In principle, Debian packages already follow the Hurd repositories well. Samuel

Builds

Hello is it possible to build Hurd disc images from git repositories? it would be cool to make one actual image as for example grub2 (installed nativelly) would make every reinstall much easier now. i guess its not easy. Thanks Jakub

[PATCH] Enable silent builds by default if available

* configure.ac (AM_SILENT_RULES): Add silent rules support if available, and enable it by default. * Makefile.am (AWK_V, AWK_V_, AWK_V_0): New variables. (NM_V, NM_V_, NM_V_0): Likewise. (GZIP_V, GZIP_V_, GZIP_V_0): Likewise. (MIGCOM_V, MIGCOM_V_, MIG

[PATCH 2/3] Enable silent builds by default if available

* configure.ac (AM_SILENT_RULES): Add silent rules support if available, and enable it by defualt. * Makefile.am (NM_V, NM_V_, NM_V_0): New variables. (gnumach-undef): Use NM_V in front of NM. (gnumach-undef-bad): Use AM_V_GEN in front of sed. (clib-routines.o): Use AM_V_at in fron of undefined sym

Re: [PATCH 1/5] unionfs now builds successfully

Hello, On Sat, May 30, 2009 at 5:52 PM, wrote: > On Fri, May 29, 2009 at 12:00:30AM +0300, Sergiu Ivanov wrote: >> >From 6f3e628fa4e90ed1316b2919b2d1a7ea08986b4c Mon Sep 17 00:00:00 2001 >> From: Sergiu Ivanov >> Date: Thu, 28 May 2009 19:19:23 +0300 >> Subject: [PATCH] Update Makefile to make u

Re: [PATCH 1/5] unionfs now builds successfully

Hi, On Tue, May 26, 2009 at 11:31:49PM +0300, Sergiu Ivanov wrote: > +# Get the information from under /usr. > +prefix = /usr/ Do NOT hardcode the prefix -- it is a variable for a reason! The user can change it by setting the environment variable. (For that same reason, the title of the patch is

Re: [PATCH 1/5] unionfs now builds successfully

Hi, On Fri, May 29, 2009 at 12:00:30AM +0300, Sergiu Ivanov wrote: > >From 6f3e628fa4e90ed1316b2919b2d1a7ea08986b4c Mon Sep 17 00:00:00 2001 > From: Sergiu Ivanov > Date: Thu, 28 May 2009 19:19:23 +0300 > Subject: [PATCH] Update Makefile to make unionfs build. I wonder, is it useful to include

Re: [PATCH 1/5] unionfs now builds successfully

>From 6f3e628fa4e90ed1316b2919b2d1a7ea08986b4c Mon Sep 17 00:00:00 2001 From: Sergiu Ivanov Date: Thu, 28 May 2009 19:19:23 +0300 Subject: [PATCH] Update Makefile to make unionfs build. * Makefile: Update copyright years. Set $prefix to /usr. --- Makefile |6 +- 1 files changed, 5 insert

Re: [PATCH 1/5] unionfs now builds successfully

Hello! On Tue, May 26, 2009 at 11:31:49PM +0300, Sergiu Ivanov wrote: > diff --git a/Makefile b/Makefile > index b180072..3129031 100644 > --- a/Makefile > +++ b/Makefile Don't forget to update the list of copyright years. > +# Get the information from under /usr. > +prefix = /usr/ No trailing

[PATCH 1/5] unionfs now builds successfully

diff --git a/Makefile b/Makefile index b180072..3129031 100644 --- a/Makefile +++ b/Makefile @@ -17,6 +17,9 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 # USA. +# Get the information from under /usr. +prefix = /usr/ + CPP = gcc -E -x c MIGCOM = mig -cc cat - /dev/nu