bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/4] hurd: Simplify init-first.c further


From: Samuel Thibault
Subject: Re: [PATCH v2 1/4] hurd: Simplify init-first.c further
Date: Fri, 24 Feb 2023 02:08:09 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Sergey Bugaev, le jeu. 23 févr. 2023 16:54:05 +0300, a ecrit:
> And from what I remember from building glibc on the Hurd
> itself back in 2021, make check takes a very long time and either
> never really completes or brings the system into some weird state.

Some checks pose problem indeed, see the "unsupported" lines in debian's
debian/testsuite-xfail-debian.mk

> If you're able to run make check on your end, please do so (but wait
> until I send v3 with the changes you've requested below).

I'll let it run through the night.

> Are there specific tests for the various combinations of startup
> variants? (shared vs static, args already on the stack vs not, exec
> server present vs not)

Basically it's the elf/ directory that tests things. I don't know which
ones would exactly test what you'd want, there are various tests for
various situations.

> Instead of returning, _hurd_startup invokes a callback (doinit) that
> (eventually) just sets the stack pointer to point to this data (so it
> now is on the top of the stack, just as _start1 expects) and jumps to
> _hurd_stack_setup's caller (i.e. to _start).

Ah, ok, I had misunderstood and I hadn't really dived into the code. I
thought _hurd_startup was eventually calling main() itself, but actually
no it's sorta-returning to _start, but lower in the stack.

Your current comments are enough, I was just stuck with older
assumptions with the old stack switching code.

Thanks!
Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]