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


>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.