Re: [Bug binutils/10263] New: objdump does not disassemble ARM code entered with .word directives
Hi Mike, It used to be possible to enter instructions with .word directives and then disassemble them with objdump -d, but that no longer works. Example: mov r0, r1 .word 0xe1a1 bx lr 0: e1a1mov r0, r1 4: e1a1.word 0xe1a1 8: e12fff1ebx lr This is actually the intended behaviour. The .word directive is used to enter data not instructions and the ARM port of GAS makes a note of this by emitting a local mapping symbol. For example if you run: armv5tel-unknown-linux-gnueabi-readelf --syms test.o You will see: Symbol table '.symtab' contains 9 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT3 3: 0 SECTION LOCAL DEFAULT4 4: 0 NOTYPE LOCAL DEFAULT1 $a 5: 0004 0 NOTYPE LOCAL DEFAULT1 $d 6: 0008 0 NOTYPE LOCAL DEFAULT1 $a It is the $d symbol, entry number 5 in the symbol table, which is telling the disassemble that the word at 0x0004 is not an instruction but data and so it should not attempt to disassemble it. It would be possible to add a new pseudo-op, say .insn, to insert a numeric value into the output and have it be labelled as in instruction, but why bother ? Do you really need this functionality. Why not just assemble the instruction normally ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10263] objdump does not disassemble ARM code entered with .word directives
--- Additional Comments From nickc at redhat dot com 2009-06-12 12:22 --- Subject: Re: New: objdump does not disassemble ARM code entered with .word directives Hi Mike, It used to be possible to enter instructions with .word directives and then disassemble them with objdump -d, but that no longer works. Example: mov r0, r1 .word 0xe1a1 bx lr 0: e1a1mov r0, r1 4: e1a1.word 0xe1a1 8: e12fff1ebx lr This is actually the intended behaviour. The .word directive is used to enter data not instructions and the ARM port of GAS makes a note of this by emitting a local mapping symbol. For example if you run: armv5tel-unknown-linux-gnueabi-readelf --syms test.o You will see: Symbol table '.symtab' contains 9 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT3 3: 0 SECTION LOCAL DEFAULT4 4: 0 NOTYPE LOCAL DEFAULT1 $a 5: 0004 0 NOTYPE LOCAL DEFAULT1 $d 6: 0008 0 NOTYPE LOCAL DEFAULT1 $a It is the $d symbol, entry number 5 in the symbol table, which is telling the disassemble that the word at 0x0004 is not an instruction but data and so it should not attempt to disassemble it. It would be possible to add a new pseudo-op, say .insn, to insert a numeric value into the output and have it be labelled as in instruction, but why bother ? Do you really need this functionality. Why not just assemble the instruction normally ? Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=10263 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10263] objdump does not disassemble ARM code entered with .word directives
--- Additional Comments From mikpe at it dot uu dot se 2009-06-12 15:31 --- Nick, (In reply to comment #1) mov r0, r1 .word 0xe1a1 bx lr 0: e1a1mov r0, r1 4: e1a1.word 0xe1a1 8: e12fff1ebx lr This is actually the intended behaviour. The .word directive is used to enter data not instructions and the ARM port of GAS makes a note of this by emitting a local mapping symbol. For example if you run: armv5tel-unknown-linux-gnueabi-readelf --syms test.o You will see: Symbol table '.symtab' contains 9 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT3 3: 0 SECTION LOCAL DEFAULT4 4: 0 NOTYPE LOCAL DEFAULT1 $a 5: 0004 0 NOTYPE LOCAL DEFAULT1 $d 6: 0008 0 NOTYPE LOCAL DEFAULT1 $a It is the $d symbol, entry number 5 in the symbol table, which is telling the disassemble that the word at 0x0004 is not an instruction but data and so it should not attempt to disassemble it. From my perspective, the interpretation of a binary value should primarily be a function of the type of the section it occurs in, not the mechanism used to put it there (in this case, .word or symbolic mov r0, r1). However, I do realise that ARM's use of literals pools embedded in .text segments makes it appealing to not disassembe data values in .text segments. It would be possible to add a new pseudo-op, say .insn, to insert a numeric value into the output and have it be labelled as in instruction, but why bother ? Do you really need this functionality. Why not just assemble the instruction normally ? There are debugging situations where all one gets is some raw object code, and as a first step one wants to determine the corresponding symbolic form. A standard way to do that is to cat test.s .text .globl foo foo: .word 0x... ^D as -o test.o test.s; objdump -d test.o That approach works on pretty much any arch I've ever used, except for recent binutils releases on ARM. Here are two recent real-life situations where I've needed this feature: 1. Two months ago I was rebuilding lots of user-space source packages on my ARM boxes and noticed many alignment trap warnings in the kernel log from one specific package. The kernel log only lists the instruction opcodes in hex, so I used the above-mentioned recipe to convert the hex values to symbolic form, except objdump refused to do so. That left me thoroughly confused, and for a while I wondered if the toolchain had generated invalid object code. One could try starting the program with gdb and using gdb's disassembler to inspect those instruction, but that won't work if the addresses of those instructions vary from run to run (think JITs or .so loading + randomisation). 2. I've been involved with the development of a dynamic binary instrumentation tool for x86. Occasionally the tool would find an application instruction that it could decode but not translate/instrument. In those cases it would include the binary representation of the instruction in the error log. Again, to debug this one wants to map that binary representation back to symbolic form, and the above-mentioned recipe is a practical way to do that (with s/.word/.byte/g). An .insn or .cword (for code .word) directive would solve debugging problems like mine. /Mikael -- http://sourceware.org/bugzilla/show_bug.cgi?id=10263 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10269] New: IFUNC gas problem
#ifndef PICKNO
# define PICKNO 1
#endif
#if PICKNO == 2
# define PICK(fn1, fn2) #fn2
#else
# define PICK(fn1, fn2) #fn1
#endif
#ifdef __x86_64__
# define IFUNC_ASM(fn) \tleaq fn (%rip), %rax\n\tretq\n
#endif
#define IFUNC(name, globl, fn1, fn2) \
extern __typeof (fn1) fn1 __attribute__((used));\
extern __typeof (fn2) fn2 __attribute__((used));\
extern __typeof (fn1) name;\
asm (globl #name \n\
\t.type #name , @gnu_indirect_function\n\
#name :\n\
IFUNC_ASM (PICK (fn1, fn2))\
\t.size #name , .- #name \n)
#define IFUNC_LOCAL(name, fn1, fn2) IFUNC(name, .local, fn1, fn2)
#define IFUNC_GLOBAL(name, fn1, fn2) IFUNC(name, .globl, fn1, fn2)
static int foo1 (void) { return 1; }
static int foo2 (void) { return 2; }
IFUNC_LOCAL (foo, foo1, foo2);
extern void abort (void);
int
main (void)
{
if (foo () != PICKNO)
abort ();
return 0;
}
In this case IMHO gas should create R_*_IRELATIVE relocation against the local
foo symbol. If foo is .globl or .globl and .hidden, it works correctly.
--
Summary: IFUNC gas problem
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gas
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=10269
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10270] New: IFUNC local symbol
See ifunc3 testcase in http://sources.redhat.com/ml/binutils/2009-06/msg00199.html If binary overrides some shared library's symbol with its STT_GNU_IFUNC symbol and the binary takes address of that symbol, the symbol defined in the binary shouldn't be IMHO STT_GNU_IFUNC pointing to the indirect function, but normal symbol pointing to the PLT slot (which will have R_*_IRELATIVE relocation for its .got.plt), otherwise pointer comparisons don't work well. -- Summary: IFUNC local symbol Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: jakub at redhat dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10270 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10269] IFUNC gas problem
-- What|Removed |Added AssignedTo|unassigned at sources dot |hjl dot tools at gmail dot |redhat dot com |com Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=10269 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10270] IFUNC local symbol
-- What|Removed |Added AssignedTo|unassigned at sources dot |hjl dot tools at gmail dot |redhat dot com |com Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=10270 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10271] New: build fails for sh2a
When I try to build GCC 4.4.0 with binutils 2.19.1 for sh2a (Hitachi SuperH) I get the following: Internal error, aborting at /var/tmp/cross/sh2a-linux-uclibc/por tage/cross-sh2a-linux-uclibc/binutils-2.19.1-r1/work/binutils-2.19.1/gas/config/ tc-sh.c line 3968 in md_apply_fix Please report this bug. So here I am... This happens with Buildroot (on i386) as well as in Gentoo Crossdev (on x86_64 as reported here) -- Summary: build fails for sh2a Product: binutils Version: 2.19 Status: NEW Severity: critical Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: ce at embedded-software dot de CC: bug-binutils at gnu dot org GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: sh2a-linux-uclibc http://sourceware.org/bugzilla/show_bug.cgi?id=10271 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10271] build fails for sh2a
--- Additional Comments From ce at embedded-software dot de 2009-06-12 17:25 --- Created an attachment (id=3991) -- (http://sourceware.org/bugzilla/attachment.cgi?id=3991action=view) This is the complete log of the build. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10271 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10271] build fails for sh2a
--- Additional Comments From ce at embedded-software dot de 2009-06-12 17:25 --- I assigned this bug to GCC as well bug # 40428 -- http://sourceware.org/bugzilla/show_bug.cgi?id=10271 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10270] IFUNC local symbol
--- Additional Comments From jakub at redhat dot com 2009-06-12 19:10 --- The problem with using normal symbol is that if some shared library calls such a symbol, the .got.plt slot in the shared library will contain address of the .plt slot in the binary and only its .got.plt will contain the resolved function that should be called, so in that (hopefully rare, IFUNC doesn't make as much sense in the binaries as it does in shared libraries and binary overriding symbols in shared libraries is also not so common) case calls from the shared library need to hop through two .plt slots. But I don't see other ways how to make pointer comparisons work in this case. Obviously if the binary doesn't take its address, using IFUNC symbol in the binary is just fine. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10270 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10270] IFUNC local symbol
-- What|Removed |Added CC||drepper at redhat dot com, ||roland at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=10270 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10271] build fails for sh2a
--- Additional Comments From kkojima at rr dot iij4u dot or dot jp 2009-06-12 21:58 --- It looks a duplicate of PR6750. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10271 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10271] build fails for sh2a
--- Additional Comments From ce at embedded-software dot de 2009-06-13 01:32 --- Not really, but it is a problem of the SH2A configuration not really supported on GCC 4.4.0 as I found out (sadly). (In reply to comment #3) It looks a duplicate of PR6750. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://sourceware.org/bugzilla/show_bug.cgi?id=10271 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
