Re: reliable reproducer, was Re: core dump analysis
Michael Schmitz <[email protected]>
| Newsgroups | gmane.linux.ports.m68k,gmane.linux.debian.ports.68k |
|---|---|
| Message-ID | <[email protected]> |
Hi Andreas,
Am 22.04.2023 um 22:12 schrieb Andreas Schwab:
> On Apr 22 2023, Michael Schmitz wrote:
>
>> This is the definition from the kernel's
>> include/uapi/asm-generic/ucontext.h:
>
> That's not actually used by m68k, it uses
> arch/m68k/include/asm/ucontext.h, which confusingly isn't an uapi
> header.
Argh - not sure how I missed that one.
>> And this is /usr/include/sys/ucontext.h:
>>
>> /* Userlevel context. */
>> typedef struct ucontext
>> {
>> unsigned long int uc_flags;
>> struct ucontext *uc_link;
>> __sigset_t uc_sigmask;
>> stack_t uc_stack;
>> mcontext_t uc_mcontext;
>> long int uc_filler[174];
>> } ucontext_t;
>>
>> uc_sigmask appears before uc_stack and uc_mcontext.
>
> Yes, that got fixed as part of commit 9c986f878a back in 2006.
With the header corrected as per arch/m68k/include/asm/ucontext.h, I get
the correct information in uc_filler[54] aka fmtvec now. Good. Every
sigreturn possibly overwrites the user stack now (if the filler is used
in full). Not so good.
>> I'm assuming libc just passes on what the kernel set, without reordering?
>
> Trying to rewrite the signal context would be prohibitive, yes.
Now I wonder who adds sigmask ... and whether that's also ending up on
the user stack.
Cheers,
Michael
>