This is the mail archive of the binutils@sourceware.org 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]

RFA: objdump -D on binary files and 64-bit address spaces


When running objdump -D on a binary file (say, a dump directly from
memory of dynamically-generated code), you can use the -m and -M
options to specify the target architecture, but that's not quite
enough. If the --adjust-vma option is used to place the dumped code at
a large (> 2^32) address, objdump still prints addresses truncated to
32 bits. For example:

$ objdump  -D -b binary -m i386 -M x86-64
--adjust-vma=0x00007f9fa10747e0 --start-address=0x00007f9fa10c7f90
--stop-address=0x00007f9fa10c88b0 --no-show-raw dump

Disassembly of section .data:

a10c7f90 <.data+0x537b0>:
a10c7f90:       mov    %eax,-0x14000(%rsp)
a10c7f97:       push   %rbp
a10c7f98:       sub    $0x50,%rsp
a10c7f9c:       mov    %rdx,0x10(%rsp)
a10c7fa1:       mov    0xc(%rsi),%r13d
a10c7fa5:       test   %r13d,%r13d

This is because objdump calls bfd_sprintf_vma to print the address
before calling the disassembler to print the rest of the line. That
routine checks the arch_info of the BFD to see how wide an address is,
and truncates to 32 bits because arch_info defaults to the default
target (which, on x86 machines, is i386; this may or may not be an
issue on other architectures that have both 32-bit and 64-bit
support).

I'm looking for advice on how to fix this. We could have an option for
objdump to force 64-bit addresses, or to set the target for the BFD it
creates for a binary file. We could add a "binary64" file type to BFD.
We could have objdump query the disassembler for address size and poke
that into bfd->arch_info. Any other suggestions?

-cary


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