public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@zembu.com>
To: geoffk@ozemail.com.au
Cc: mark@codesourcery.com, gavin@cygnus.com,
	binutils@sourceware.cygnus.com, brendan@cygnus.com
Subject: Re: Reloc changes to bfd/elf32-mips.c
Date: Wed, 06 Oct 1999 19:35:00 -0000	[thread overview]
Message-ID: <19991007023447.2184.qmail@daffy.airs.com> (raw)
In-Reply-To: <199910070151.LAA01021@gluttony.geoffk.wattle.id.au>

   Date: Thu, 7 Oct 1999 11:51:21 +1000
   From: Geoff Keating <geoffk@ozemail.com.au>

   Perhaps you could explain what you think the code should be doing?
   This is often much more helpful than simply saying `I think this is
   wrong', since the usual response is `well, I think it is right'.

Sorry, I thought I had explained it.

I think that the 32 bit MIPS ELF code should compute a 64 bit reloc by
computing a 32 bit reloc in the least significant 32 bits.  The most
significant bit of the result of that computation should then be sign
extended into the most significant 32 bits.

This behaviour is independent of whether BFD64 is defined or not.
BFD64 is a host macro, and I am concerned with target behaviour.

   My test case for this is the following:

   configure --target=mipstx39-unknown-elf
   make
   cat > test.s <<EOF
      .text
   l1:
      .dword l1+16
   EOF
   gas/as-new test.s -o test.o
   ld/ld-new -Ttext 0x12345678 test.o -o test.out
   binutils/objdump -j .text -s test.out

   and without my patch I see

   Contents of section .text:
    12345678 00000000 12345678                    .....4Vx        

   when I expect to see

   Contents of section .text:
    12345678 00000000 12345688                    .....4V.        

I agree that the code should produce what you expect to see.  I don't
know whether this build used BFD64 or not.

Your patch changed several different things at once.  I don't know
which are necessary to make this result.  Most of your patch looked
fine.  The odd parts were the two hunks which added #ifndef BFD64 and
#endif, and the last hunk which didn't set howto.  I don't understand
all of this code.  But especially adding the #ifndef/#endif seems
strange.

As I've tried to say before, if the three hunks I mentioned don't
change what happens, then they are fine.  If they do change what
happens, then I would like to understand how they change it.  Can you
explain that?

Ian

  reply	other threads:[~1999-10-06 19:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-27  4:30 Geoff Keating
1999-09-27 12:37 ` Mark Mitchell
1999-09-28  0:54 ` Mark Mitchell
1999-09-28  6:57   ` Ian Lance Taylor
1999-09-28 20:32   ` Geoff Keating
1999-09-28 20:57     ` Ian Lance Taylor
1999-09-28 21:52       ` Geoff Keating
1999-09-28 22:03         ` Ian Lance Taylor
1999-10-06 19:21           ` Geoff Keating
1999-10-06 19:35             ` Ian Lance Taylor [this message]
1999-10-06 20:39               ` Geoff Keating
1999-10-06 20:53                 ` Ian Lance Taylor
1999-10-07  4:47                   ` Geoff Keating
1999-10-07  7:28                     ` Ian Lance Taylor
1999-10-07  9:17                     ` Mark Mitchell
1999-09-28 22:16     ` Mark Mitchell
1999-09-29  8:25       ` Ian Lance Taylor
  -- strict thread matches above, loose matches on Subject: below --
1999-09-27  4:24 Geoff Keating
1999-09-27 18:25 ` Ian Lance Taylor

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=19991007023447.2184.qmail@daffy.airs.com \
    --to=ian@zembu.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=brendan@cygnus.com \
    --cc=gavin@cygnus.com \
    --cc=geoffk@ozemail.com.au \
    --cc=mark@codesourcery.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).