Sergey Bugaev wrote:
> Looking at [0]: 'int code' should be 'long code', otherwise you won't
> be able to extract the full 64-bit address from it.
Good point, thanks! I've changed libsigsegv and gnulib accordingly.
> I don't know how
> this works out for the BSDs -- maybe they just don't pass the
Sergey Bugaev wrote:
> state->basic is the Mach i386_thread_state structure; the
> signal handling machinery first initializes it using thread_get_state
> ()) to describe the state that the thread had at the time it was
> interrupted. It then initializes the sigcontext based on this state
> (memcpy
Looking at [0]: 'int code' should be 'long code', otherwise you won't
be able to extract the full 64-bit address from it. I don't know how
this works out for the BSDs -- maybe they just don't pass the address
in there?
[0]:
https://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=src/fault-
On Sun, May 14, 2023 at 5:11 PM Bruno Haible wrote:
> But another thing appears to be wrong: The role of sc_rsp versus sc_ursp
> in glibc/sysdeps/mach/hurd/x86_64/bits/sigcontext.h.
>
> What glibc/sysdeps/mach/hurd/x86/trampoline.c does for x86_64 is:
>
> _hurd_setup_sighandler (...)
> {
> ...
>
Hello Sergey,
> > * glibc/sysdeps/mach/hurd/x86_64/bits/sigcontext.h lines 57..79
> > * glibc/sysdeps/mach/hurd/x86/trampoline.c lines 239..247.
> > This code copies the values from the stack into a 'struct sigcontext'.
> > But here the order of the registers is
>
> No: trampoline.c copies th
Hello,
On Fri, May 12, 2023 at 10:12 PM Bruno Haible wrote:
> * glibc/sysdeps/mach/hurd/x86_64/bits/sigcontext.h lines 57..79
> * glibc/sysdeps/mach/hurd/x86/trampoline.c lines 239..247.
> This code copies the values from the stack into a 'struct sigcontext'.
> But here the order of the regis
Hi,
While trying to understand the patch submitted at
https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00048.html
I'm looking at three files:
* gnumach/x86_64/locore.S lines 512..519
ENTRY(alltraps)
pusha /* save the general registers */
trap_push_segs
