Hi Finn,
Am 24.04.2023 um 15:51 schrieb Michael Schmitz:
Hi Andreas,
On 24/04/23 09:48, Andreas Schwab wrote:
On Apr 24 2023, Michael Schmitz wrote:
Not sure what third argument you referred to in another mail.
See struct sigframe and struct rt_sigframe. The non-rt signal handler
gets
Hi Andreas,
On 24/04/23 09:48, Andreas Schwab wrote:
On Apr 24 2023, Michael Schmitz wrote:
Not sure what third argument you referred to in another mail.
See struct sigframe and struct rt_sigframe. The non-rt signal handler
gets signal number, vector number and sigcontext*. The rt signal
On Apr 24 2023, Michael Schmitz wrote:
> Not sure what third argument you referred to in another mail.
See struct sigframe and struct rt_sigframe. The non-rt signal handler
gets signal number, vector number and sigcontext*. The rt signal
handler gets signal number, siginfo* and ucontext*.
--
Hi Finn,
On 23/04/23 19:46, Finn Thain wrote:
On Wed, 19 Apr 2023, Michael Schmitz wrote:
I wonder what we'd see if we patched the kernel to log every user data
write fault caused by a MOVEM instruction. I'll try to code that up.
If these instructions did always cause stack corruption on
Hi Finn,
On 23/04/23 21:23, Finn Thain wrote:
On Sun, 23 Apr 2023, Michael Schmitz wrote:
Am 23.04.2023 um 13:41 schrieb Michael Schmitz:
Though the question remains - is this expected behaviour for programs
that do deep recursion on the stack while taking signals (and the reason
for the
Hi Andreas,
On 23/04/23 20:23, Andreas Schwab wrote:
On Apr 23 2023, Michael Schmitz wrote:
Wasn't too hard actually. The signo parameter passed to the handler turns
out to be passed by reference, and signo is located 4 bytes into the
kernel sigframe.
That's not "passed by reference".
Hello!
I'm currently trying to fix a bug [1] in the M68k backend in LLVM.
The problem is that the backend tries to emit RTD when the baseline
is raised to at least 68020 using the -m68020 command line flag and
then crashes.
Looking at the code [2], this happens because the backend runs into
On Sun, 23 Apr 2023, Michael Schmitz wrote:
> Am 23.04.2023 um 13:41 schrieb Michael Schmitz:
>
> Though the question remains - is this expected behaviour for programs
> that do deep recursion on the stack while taking signals (and the reason
> for the option to run signal handlers on an
On Apr 23 2023, Michael Schmitz wrote:
> Wasn't too hard actually. The signo parameter passed to the handler turns
> out to be passed by reference, and signo is located 4 bytes into the
> kernel sigframe.
That's not "passed by reference". Function arguments are always passed
on the stack.
--
Hi Finn, Andreas,
Am 23.04.2023 um 13:41 schrieb Michael Schmitz:
Hi Andreas,
Am 23.04.2023 um 08:46 schrieb Andreas Schwab:
On Apr 23 2023, Michael Schmitz wrote:
I'll see whether the signal context is available on the stack even if
the
handler isn't passed that parameter.
The signal
On Wed, 19 Apr 2023, Michael Schmitz wrote:
> > I wonder what we'd see if we patched the kernel to log every user data
> > write fault caused by a MOVEM instruction. I'll try to code that up.
>
> If these instructions did always cause stack corruption on 030, I think
> we would have noticed
On Apr 23 2023, Michael Schmitz wrote:
> Hi Andreas,
>
> Am 23.04.2023 um 08:46 schrieb Andreas Schwab:
>> On Apr 23 2023, Michael Schmitz wrote:
>>
>>> I'll see whether the signal context is available on the stack even if the
>>> handler isn't passed that parameter.
>>
>> The signal context is
12 matches
Mail list logo
