From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: binutils@sourceware.org
Cc: gdb-patches@sourceware.org
Subject: [patch] bfd/: bfd_elf_bfd_from_remote_memory 32bit &= 0xffffffff
Date: Thu, 11 Feb 2010 11:57:00 -0000 [thread overview]
Message-ID: <20100211115730.GA7358@host0.dyn.jankratochvil.net> (raw)
Hi,
CORE_ADDR can be 64bit while gdb (bfd) can handle 32bit inferiors (either when
gdb host is e.g. x86_64 or when --enable-64-bit-bfd is in use). Currently gdb
(bfd) leaves garbage at the bits 32..63 and clear it only at the last moment
when required (such as when calling ptrace or printing it to the user).
There has been a conclusion gdb (bfd) should rather keep the bits cleared (so
that for example addr1 == addr2 is easily possible):
http://sourceware.org/ml/gdb-patches/2010-01/msg00497.html
# Wouldn't it be more natural to force a canonical representation at
# the time the address is *determined* in the first place?
http://sourceware.org/ml/gdb-patches/2006-09/msg00197.html
# If we have garbage in the high bits, that's a problem already.
Asking if bfd will follow this policy; otherwise the result from
bfd_elf_bfd_from_remote_memory can be also only masked in gdb/.
I had to fixup gdb/ as currently it worked thanksfully due to bfd/ returning
the right magic bits 32..63.
(gdb) p/x loadbase
$1 = 0xffffffff0033b000
(There will follow a gdb/-only patch to handle 64->32 more systematically.)
No regressions on {x86_64,i686}-fedora12-linux-gnu for binutils. But binutils
itself does not call bfd_from_remote_memory at all. No regressions on
{x86_64,x86_64-m32,i686}-fedora12-linux-gnu for gdb with the gdb/ part.
bfd/
2010-02-11 Jan Kratochvil <jan.kratochvil@redhat.com>
Clear unused bits 32..63 for ELFCLASS32.
* elfcode.h (NAME(_bfd_elf,bfd_from_remote_memory)): New variable vaddr,
use it for target_read_memory.
(NAME(_bfd_elf,bfd_from_remote_memory) <ELFCLASS == ELFCLASS32>): New.
gdb/
2010-02-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* symfile-mem.c: (symbol_file_add_from_memory): New variable addr_bit.
Mask sai->other[i].addr with it.
--- a/bfd/elfcode.h
+++ b/bfd/elfcode.h
@@ -1745,6 +1745,8 @@ NAME(_bfd_elf,bfd_from_remote_memory)
if (!loadbase_set && (i_phdrs[i].p_offset & -i_phdrs[i].p_align) == 0)
{
loadbase = ehdr_vma - (i_phdrs[i].p_vaddr & -i_phdrs[i].p_align);
+ if (ELFCLASS == ELFCLASS32)
+ loadbase &= 0xffffffff;
loadbase_set = TRUE;
}
@@ -1789,11 +1791,13 @@ NAME(_bfd_elf,bfd_from_remote_memory)
bfd_vma start = i_phdrs[i].p_offset & -i_phdrs[i].p_align;
bfd_vma end = (i_phdrs[i].p_offset + i_phdrs[i].p_filesz
+ i_phdrs[i].p_align - 1) & -i_phdrs[i].p_align;
+ bfd_vma vaddr = (i_phdrs[i].p_vaddr + loadbase) & -i_phdrs[i].p_align;
+
+ if (ELFCLASS == ELFCLASS32)
+ vaddr &= 0xffffffff;
if (end > (bfd_vma) contents_size)
end = contents_size;
- err = target_read_memory ((loadbase + i_phdrs[i].p_vaddr)
- & -i_phdrs[i].p_align,
- contents + start, end - start);
+ err = target_read_memory (vaddr, contents + start, end - start);
if (err)
{
free (x_phdrs);
--- a/gdb/symfile-mem.c
+++ b/gdb/symfile-mem.c
@@ -72,6 +73,7 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, char *name,
bfd_vma loadbase;
struct section_addr_info *sai;
unsigned int i;
+ int addr_bit = gdbarch_addr_bit (target_gdbarch);
if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
error (_("add-symbol-file-from-memory not supported for this target"));
@@ -103,6 +105,9 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, char *name,
if ((bfd_get_section_flags (nbfd, sec) & (SEC_ALLOC|SEC_LOAD)) != 0)
{
sai->other[i].addr = bfd_get_section_vma (nbfd, sec) + loadbase;
+ if (addr_bit < (sizeof (ULONGEST) * HOST_CHAR_BIT))
+ sai->other[i].addr &= ((ULONGEST) 1 << addr_bit) - 1;
+
sai->other[i].name = (char *) bfd_get_section_name (nbfd, sec);
sai->other[i].sectindex = sec->index;
++i;
next reply other threads:[~2010-02-11 11:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-11 11:57 Jan Kratochvil [this message]
2010-02-11 12:13 ` Andreas Schwab
2010-02-11 12:43 ` Jan Kratochvil
[not found] ` <20100211124302.GA8435__38068.0548646071$1265892205$gmane$org@host0.dyn.jankratochvil.net>
2010-02-16 23:24 ` Tom Tromey
2010-02-17 11:34 ` Jan Kratochvil
2010-02-17 18:50 ` Tom Tromey
2010-02-20 0:43 ` Jan Kratochvil
2010-02-11 12:51 ` Mark Kettenis
2010-02-11 13:30 ` [cancelled] " Jan Kratochvil
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=20100211115730.GA7358@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
/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