It branches to "trap_setup" which is what sets
up %g6 via the LOAD_CURRENT() macro we discussed
earlier.
Thanks, I found the bug: PS flag was always equal to S, so %g6 was assumed
OK. Now we reach the userland:
RAMDISK: Loading 64KiB [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesys
On Mon, 21 Feb 2005 19:56:51 +0100
"Blue Swirl" <[EMAIL PROTECTED]> wrote:
> (SAVE_ALL and WRITE_PAUSE don't touch %g6)
Incorrect, look at what SAVE_ALL does.
It branches to "trap_setup" which is what sets
up %g6 via the LOAD_CURRENT() macro we discussed
earlier.
-
To unsubscribe from this list:
Hi,
%g6 is loaded at "arch/sparc/kernel/etrap.S:trap_setup_from_user" by the
"LOAD_CURRENT()" macro.
Yes, I used that when patching.
At context switch time, it is updated by the switch_to() macro.
There has been no context switch yet.
At bootup, the first cpu sets up it's %g6 in arch/sparc/kernel/h
On Sun, 20 Feb 2005 19:48:55 +0100
"Blue Swirl" <[EMAIL PROTECTED]> wrote:
> Qemu's Sparc32 system emulator is getting to the point where the first user
> space application almost executes. But there is some strangeness with
> kernel's use of %g6, it's used for example in do_sparc_fault, but not
Hi,
Qemu's Sparc32 system emulator is getting to the point where the first user
space application almost executes. But there is some strangeness with
kernel's use of %g6, it's used for example in do_sparc_fault, but nothing is
restoring it before that, so there is a kernel zero page access as a
