Applied, thanks!
pasha (biblio), le ven. 12 mai 2023 00:51:21 +0200, a ecrit:
> >On Thu, 2023-05-11 at 02:06 +0200, Samuel Thibault wrote:
>
> >pasha (biblio), le mar. 09 mai 2023 17:01:08 +0200, a ecrit:
> >Add example of 64-bit debugging.
>
> >Mmm, rather extend the QEMU section of
> >https://
Applied, thanks!
Sergey Bugaev, le jeu. 11 mai 2023 22:28:59 +0300, a ecrit:
> ...like it's already done when exiting a trap. This is required, since
> handing a syscall can result in an AST; in particular this happens when
> the current thread is being terminated, which sets AST_TERMINATE and
> e
Sergey Bugaev, le jeu. 11 mai 2023 18:25:43 +0300, a ecrit:
> On Thu, May 11, 2023 at 6:02 PM Samuel Thibault
> wrote:
> > See the commit I had just pushed ;)
>
> Hm, but that doesn't make sense to me. If we want a particular tool --
> Unix uname(1) -- to output "i386" when running i386-gnu soft
>On Thu, 2023-05-11 at 02:06 +0200, Samuel Thibault wrote:
>pasha (biblio), le mar. 09 mai 2023 17:01:08 +0200, a ecrit:
>Add example of 64-bit debugging.
>Mmm, rather extend the QEMU section of
>https://darnassus.sceen.net/~hurd-web/microkernel/mach/gnumach/debugging/
---
microkernel/mach/gnum
Applied, thanks!
Sergey Bugaev, le jeu. 11 mai 2023 16:58:43 +0300, a ecrit:
> Commit 31dd30a94a682955c3c9e2f42252b4a07687067a "add setting gs/fsbase"
> added the code to set fs and gs bases on context_switch. However, this
> was only being done when switching context via the explicit
> switch_con
...like it's already done when exiting a trap. This is required, since
handing a syscall can result in an AST; in particular this happens when
the current thread is being terminated, which sets AST_TERMINATE and
expects the thread to never return to userspace.
Fixes a kernel crash upon calling exi
* Sergey Bugaev:
> Do user programs in practice rely on the fact that pthread
> cancellation does unwinding and so calls object destructors, runs
> @finally clauses, etc?
I think so, yes. I don't recall introducing a regression in that part
of cancellation, so we don't have good usage data unfor
On Thu, May 11, 2023 at 9:12 PM Florian Weimer wrote:
> I'd expect __pthread_setcancelstate to act on asynchronous cancellation
> if it is enabled. Once you implement that and have a strong symbol
> reference to __pthread_setcancelstate, you'd pull in the cancellation
> unwinder without additiona
* Sergey Bugaev:
>> If you need async cancellation support, the core cancellation routine
>> could be made weak, so that it is linked into the executable only if
>> pthread_cancel is ever called.
>
> Could you please expand on how this all (unwinding, async
> cancellation) is relevant? Clearly cal
On Thu, May 11, 2023 at 8:44 PM Florian Weimer wrote:
> Apparently, Hurd does not support async cancellation? Then
> __pthread_setcancelstate never has to unwind, so you just turn it into a
> non-weak symbol.
It does in theory, htl/pt-cancel.c has a PTHREAD_CANCEL_ASYNCHRONOUS
branch that calls i
* Samuel Thibault:
> Florian Weimer, le jeu. 11 mai 2023 19:44:42 +0200, a ecrit:
>> * Sergey Bugaev:
>> > Clearly __pthread_setcancelstate has been pragma weak'd, and used here
>> > without a check. This is a statically linked x86_64-gnu (so, Hurd and
>> > HTL) executable. Commit 93d78ec1cba68184
Florian Weimer, le jeu. 11 mai 2023 19:44:42 +0200, a ecrit:
> * Sergey Bugaev:
> > Clearly __pthread_setcancelstate has been pragma weak'd, and used here
> > without a check. This is a statically linked x86_64-gnu (so, Hurd and
> > HTL) executable. Commit 93d78ec1cba68184931b75bef29afd3aed30f43a
>
* Sergey Bugaev:
> Clearly __pthread_setcancelstate has been pragma weak'd, and used here
> without a check. This is a statically linked x86_64-gnu (so, Hurd and
> HTL) executable. Commit 93d78ec1cba68184931b75bef29afd3aed30f43a
> "nptl: Move pthread_setcancelstate into libc" seems to be the culpr
Hello,
I'm hitting a crash with the following backtrace:
#0 0x in ?? ()
#1 0x004660dd in __error_internal (status=1,
errnum=1073741826, message=0x9adcef1c, args=0x9adcef18,
args@entry=0x156aa48, mode_flags=2598170400, mode_flags@entry=0) at
error.c:243
#2 0x0046
On Thu, May 11, 2023 at 6:02 PM Samuel Thibault wrote:
> See the commit I had just pushed ;)
Hm, but that doesn't make sense to me. If we want a particular tool --
Unix uname(1) -- to output "i386" when running i386-gnu software on
x86_64 hardware (and I don't actually know whether we want that,
Sergey Bugaev, le jeu. 11 mai 2023 17:57:32 +0300, a ecrit:
> Hasn't that broken USER32 though? As-is (without this patch),
See the commit I had just pushed ;)
Samuel
On Thu, May 11, 2023 at 5:34 PM Samuel Thibault wrote:
> Note that I have added to gnumach CPU_TYPE_X86_64, used on 64bit gnumach
> so that uname -m properly reports a 64bit architecture. So you'll rather
> add the case CPU_TYPE_X86_64 there.
Oh, I see -- that wasn't in my tree when I checked.
H
Sergey Bugaev, le jeu. 11 mai 2023 17:21:06 +0300, a ecrit:
> diff --git a/exec/hostarch.c b/exec/hostarch.c
> index 363fda69..58ddc6b9 100644
> --- a/exec/hostarch.c
> +++ b/exec/hostarch.c
> @@ -70,7 +70,14 @@ elf_machine_matches_host (ElfW(Half) e_machine)
> case CPU_TYPE_I486:
> case
Since we don't support mixing i386 and x86_64 binaries on the same
system (as running them requires different build-time gnumach
configurations), the exec server can simply require the binary being
loaded to have been built for the same architecture as the exec server
itself.
---
exec/exec.c |
Commit 31dd30a94a682955c3c9e2f42252b4a07687067a "add setting gs/fsbase"
added the code to set fs and gs bases on context_switch. However, this
was only being done when switching context via the explicit
switch_context() method, but not in other cases where the context is
switched, such as with call
...like it's already done when exiting a trap. This is required, since
handing a syscall can result in an AST; in particular this happens when
the current thread is being terminated, which sets AST_TERMINATE and
expects the thread to never return to userspace.
Fixes a kernel crash upon calling exi
21 matches
Mail list logo
