Re: longjmp question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Jurij Smakov <jurij@xxxxxxxxx>
Date: Sat, 15 Oct 2011 00:06:53 +0100

> Replacing "flushw" with "ta 0x03" makes the problem go away. What is 
> the difference between the two? I would naively think that the effect 
> of both should be saving register windows on the stack, allocating a
> new stack frame for each of them, so fp would get adjusted in either 
> case. Then I would expect that the correct fix would be to indicate to 
> the compiler that flushw is clobbering fp/sp registers, so it cannot 
> rely on their contents afterwards. The fact that using "ta 0x03" fixes 
> it makes me feel lost again :-).

Taking a trap has a side effect, in that the %g* and %o* registers
will be saved and restored by the trap entry and exit respectively.

Trap entry also grabs a register window (for the kernel), which
is restored from on trap exit.

The register window flush is performed between this trap statesave and
restore.

Furthermore, it also means that the current register window will be
saved by the "ta 0x03" case.

This is probably why certain gdb breakpoints also make the problem go
away.

Essentially, "ta 0x03" is kind of like:

	save	%sp, -WHATEVER, %sp
	flushw
	restore

so it will restore one more register window than an actual 'flushw'
in userspace would.

I'm starting to become convinced that if you look at the stack
backtrace at the time of the flushw done by ruby, you'll see that
there are multiple stack frames using the same memory regions.

I'll try to look at this more closely myself, especially since you've
given me excellent tips on how to reproduce this and run it under gdb,
but I'm currently fighting a gcc bug which I want to clear away first.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux MIPS Home]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite News]     [MIPS Architecture]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux