Red Hat Bugzilla – Bug 82886
objdump calculates the offset after ud2a wrong on i386
Last modified: 2008-05-01 11:38:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
In the kernel BUG() gets compiled into the opcode ud2a. When objdump sees this
it gets the offsets used in the disassembly all confused for a few instructions.
c024f699: 0f 0b ud2a
c024f69b: 99 cltd
c024f69c: 01 80 70 2b c0 be add %eax,0xbec02b70(%eax)
c024f6a2: 01 00 add %eax,(%eax)
c024f6a4: 00 00 add %al,(%eax)
c024f6a6: f0 0f c1 32 lock xadd %esi,(%edx)
I'm not sure what the 99 01 80 70 2b c0 is but I know that the instruction
be 01 00 00 00 should load 1 into %edx.
So it seems like the compiler is generating some additional code after the ud2a
opcode that objdump doesn't expect.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. build a kernel
2. disassemble it.
Actual Results: objdump gets confused around the ud2f instructions
Expected Results: it should expect whatever is after ud2f and deal with it.
GNU objdump 220.127.116.11.2 20020207
devi@ben:rpm -q binutils
Can you please attach a sample .s file which shows this?
Why do you need a .s file from me?
All that you have to do is objdump a vmlinux (not vmlinuz) and you will see the
Ok, I see it myself:
#define BUG() \
__asm__ __volatile__( "ud2\n" \
"\t.word %c0\n" \
"\t.long %c1\n" \
: : "i" (__LINE__), "i" (__FILE__))
There is nothing objdump can do about this thoughit has no way how to guess
kernel has 8 bytes of data in the instruction stream followed again by
If there was a jump around it, ie. ud2; jmp 1f; .word something; .long somethingelse; 1:
then objdump would dump it correctly. But it would make kernel larger.