Re: CVS commit: src/sys/arch/riscv/riscv

[Matt Thomas <matt%3am-software.com@localhost>]

> On Mar 31, 2015, at 3:12 AM, Reinoud Zandijk <reinoud%NetBSD.org@localhost> wrote:
> 
> Hi Matt,
> 
> On Tue, Mar 31, 2015 at 01:30:50AM +0000, Matt Thomas wrote:
>> When the cpu gets an exception from kernel mode, the sscratch register will be
>> 0 and curlwp will be in the "tp" register.  When the cpu gets an exception from
>> user mode, the sscratch register will be a pointer to the current lwp.
> 
> Will the kernel not be confused and choose the wrong path if a userland
> programs clears the "sp" register and gets an exception, say be storing a
> stack frame? by accident or deliberately?

No.  scrrw rd, reg, rs1 atomically swaps the contents of reg with rs1 return the old contents is rd.

So the old sp (now tp) gets put into sscratch and the contents of sscratch get put into sp (not tp).

The value upon entry doesn't matter, the contents of sscratch matter and it can't affected by user mode.

>> Index: src/sys/arch/riscv/riscv/locore.S
>> diff -u src/sys/arch/riscv/riscv/locore.S:1.1 src/sys/arch/riscv/riscv/locore.S:1.2
>> --- src/sys/arch/riscv/riscv/locore.S:1.1	Sat Mar 28 16:13:56 2015
>> +++ src/sys/arch/riscv/riscv/locore.S	Tue Mar 31 01:30:50 2015
>> @@ -1,4 +1,4 @@
>> -/* $NetBSD: locore.S,v 1.1 2015/03/28 16:13:56 matt Exp $ */
>> +/* $NetBSD: locore.S,v 1.2 2015/03/31 01:30:50 matt Exp $ */
>> /*-
>>  * Copyright (c) 2014 The NetBSD Foundation, Inc.
>>  * All rights reserved.
>> @@ -78,10 +78,10 @@ ENTRY_NP(start)
>> 	call	memset			// zero through kernel_end
>> 
>> 	// As a temporary hack, word 0 contains the amount of memory in MB
>> -	lw	a7, (zero)			// load memory size
>> +	INT_L	a7, (zero)			// load memory size
>> 	slli	a7, a7, (20-PGSHIFT)		// convert MB to pages
>> -	auipc	t0, %pcrel_hi(physmem)
>> -	sw	a7, %pcrel_lo(physmem)(t0)	// store it in physmem
>> +.L01:	auipc	t0, %pcrel_hi(physmem)
>> +	INT_S	a7, %pcrel_lo(.L01)(t0)		// store it in physmem
> 
> Why are you loading the lower PC relative part of .L01 in stead of physmem?
> won't that give the wrong lower bits? Isn't there a PTR_S macro to handle
> this?

Because that's how the relocation works.  the %pcrel_lo is dependent on the
location of the initial auipc and it's %pcrel_hi.  So %pcrel_lo uses the
address of auipc and obtains the actual symbol from the relocation at that
location.

If you assemble a simple file of:

	lla	t0, foo

and objdump -dr you'll see:

Disassembly of section .text:

0000000000000000 <.L0 >:
   0:   00000297                auipc   t0,0x0
                        0: R_RISCV_PCREL_HI20   foo
   4:   00028293                mv      t0,t0
                        4: R_RISCV_PCREL_LO12_I .L0