This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] modify crt0.S for 64-bit address targets


(added cc: to binutils list.)

Eric,

My take on this is that the problem is **not** that addu/subu are
incorrect, but rather that the address being loaded is not what's
intended!

The intended address (K0BASE) is 0xffffffff80000000, and based on your
comments (and the detection of the UNPREDICTABLE condition), I believe
that 0x0000000080000000 is being loaded instead.

The address is a sign-extended 32-bit value, the addu/subu should be
OK.


If the simulator's actually doing the right thing, and the code really
is what your description below indicates, the changed code shouldn't
work any better.  (I forget, i have some recollection that the current
sim might always truncate addresses to 32-bits.  but it's been a while
since i looked at that.  *sigh*)


I'm probably confused/mistaken but... i thought 'la' was supposed to
generate a 32-bit address (and dla generate a 64-bit address)?  Or
maybe they always generate the address of the ABI in use?  I
forget... so much change.




chris

At Wed, 6 Apr 2005 06:28:30 +0000 (UTC), "Eric Christopher" wrote:
> So, in testing mipsisa64-elf lately we were getting a number of
> UNPREDICTABLE results because of this:
> 
> 	la      t1,K0BASE
>         addu    t0,t0,t1
>         subu    t0,t0,64
> 
> Which would assemble to this:
> 
> 	ori
> 	dsll
> 
> 	addu
> 	subu
> 
> The problem is that ABI_EABI for 64-bit targets assumes 64-bit addresses
> and the doubleword shift meant that register t0 would get something that
> isn't a word value, causing unpredictable results depending on
> processor. The mips simulator flags these. Now, shifting this to using
> 64-bit instructions for 64-bit addresses seems to be the best method for
> this. I only changed the ones that the simulator would catch thinking it
> best that we only change the ones we need to. I'm perfectly happy to
> switch it to using 64-bit instructions for everything for 64-bit, but I
> think that's probably a bit much.
> 
> Tested on mipsisa64-elf and mips64-elf.
> 
> OK?
> 
> 2005-04-05  Eric Christopher  <echristo@redhat.com>
> 
> 	* mips/crt0.S: Add macros for 64-bit add/sub.
> 	(zerobss): Use when dealing with addresses.
> 
> Index: crt0.S
> ===================================================================
> RCS file: /cvs/src/src/libgloss/mips/crt0.S,v
> retrieving revision 1.9
> diff -u -p -w -r1.9 crt0.S
> --- crt0.S 26 May 2003 20:22:16 -0000 1.9
> +++ crt0.S 6 Apr 2005 02:02:55 -0000
> @@ -41,6 +41,16 @@
> # define LA(t,x) la t,x
> #endif /* __mips_embedded_pic */
> 
> +#if !defined(__mips64)
> +  /* This machine does not support 64-bit operations.  */
> +  #define ADDU addu
> +  #define SUBU subu
> +#else
> +  /* This machine supports 64-bit operations.  */
> +  #define ADDU daddu
> +  #define SUBU dsubu
> +#endif
> + 
> .comm __memsize, 12
> .comm __lstack, STARTUP_STACK_SIZE
> 
> @@ -156,11 +166,11 @@ zerobss:
> la a0, __memsize
> lw t0,0(a0) # last address of memory available
> la t1,K0BASE # cached kernel memory
> - addu t0,t0,t1 # get the end of memory address
> + ADDU t0,t0,t1 # get the end of memory address
> /* Allocate 32 bytes for the register parameters.  Allocate 16
>    bytes for a null argv and envp.  Round the result up to 64
>    bytes to preserve alignment.  */
> - subu t0,t0,64
> + SUBU t0,t0,64
> 4:
> move sp,t0 # set stack pointer
> .end zerobss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]