From: Alexandre Oliva <aoliva@redhat.com>
To: binutils@sources.redhat.com
Subject: incorrect use of bfd_arch_bits_per_address in elf32-mips.c
Date: Mon, 07 Apr 2003 20:25:00 -0000 [thread overview]
Message-ID: <or4r5ajbrz.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
It doesn't seem right to infer bfd_arch_mips_per_address when trying
to figure out whether the ABI uses 32- or 64-bit addresses. Back when
we rejected inter-linking of code for 32-bit and 64-bit ISAs, we'd
probably always get it right, but this is now allowed, so this could
possibly break o32 (and perhaps other 32-bit arches). I unfortunately
have no idea of how to trigger this particular code chunk (defining a
function with attribute constructor didn't do it), so this hasn't got
much testing. Ok to install anyway?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mips-ctor-reloc.patch --]
[-- Type: text/x-patch, Size: 1131 bytes --]
Index: bfd/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* elf32-mips.c (bfd_elf32_bfd_reloc_type_lookup): Detect (ctor)
pointer size from ABI, not arch_bits_per_address.
Index: bfd/elf32-mips.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-mips.c,v
retrieving revision 1.163
diff -u -p -r1.163 elf32-mips.c
--- bfd/elf32-mips.c 12 Mar 2003 23:05:50 -0000 1.163
+++ bfd/elf32-mips.c 7 Apr 2003 20:21:10 -0000
@@ -1440,11 +1440,12 @@ bfd_elf32_bfd_reloc_type_lookup (abfd, c
case BFD_RELOC_CTOR:
/* We need to handle BFD_RELOC_CTOR specially.
Select the right relocation (R_MIPS_32 or R_MIPS_64) based on the
- size of addresses on this architecture. */
- if (bfd_arch_bits_per_address (abfd) == 32)
- return &howto_table[(int) R_MIPS_32];
- else
+ size of addresses of the ABI. */
+ if ((elf_elfheader (abfd)->e_flags & (E_MIPS_ABI_O64
+ | E_MIPS_ABI_EABI64)) != 0)
return &elf_mips_ctor64_howto;
+ else
+ return &howto_table[(int) R_MIPS_32];
case BFD_RELOC_MIPS16_JMP:
return &elf_mips16_jump_howto;
[-- Attachment #3: Type: text/plain, Size: 289 bytes --]
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
next reply other threads:[~2003-04-07 20:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-07 20:25 Alexandre Oliva [this message]
2003-04-07 22:53 ` Daniel Jacobowitz
2003-04-08 0:37 ` Alexandre Oliva
2003-04-08 11:17 ` 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=or4r5ajbrz.fsf@free.redhat.lsd.ic.unicamp.br \
--to=aoliva@redhat.com \
--cc=binutils@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).