public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: cgd@broadcom.com
To: echristo@redhat.com
Cc: newlib@sources.redhat.com, binutils@sources.redhat.com
Subject: Re: [patch] modify crt0.S for 64-bit address targets
Date: Wed, 06 Apr 2005 06:49:00 -0000	[thread overview]
Message-ID: <yov53bu4767a.fsf@xl-sj1-02.sj.broadcom.com> (raw)
In-Reply-To: <mailpost.1112768909.17118@news-sj1-1>

(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

       reply	other threads:[~2005-04-06  6:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1112768205.5493.2.camel@localhost.localdomain>
     [not found] ` <mailpost.1112768909.17118@news-sj1-1>
2005-04-06  6:49   ` cgd [this message]
2005-04-06 11:05     ` Maciej W. Rozycki
2005-04-06 11:22       ` Thiemo Seufer
2005-04-06 14:40         ` Maciej W. Rozycki
2005-04-06 18:37     ` Eric Christopher
2005-04-06 19:31       ` Paul Koning
2005-04-06 19:35         ` Ian Lance Taylor
2005-04-06 21:35         ` Eric Christopher
2005-04-06 18:51 cgd
2005-04-06 19:01 ` Eric Christopher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yov53bu4767a.fsf@xl-sj1-02.sj.broadcom.com \
    --to=cgd@broadcom.com \
    --cc=binutils@sources.redhat.com \
    --cc=echristo@redhat.com \
    --cc=newlib@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).