Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 82886 - objdump calculates the offset after ud2a wrong on i386
Summary: objdump calculates the offset after ud2a wrong on i386
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: binutils
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-28 04:20 UTC by Ben Woodard
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-18 21:17:39 UTC

Attachments (Terms of Use)

Description Ben Woodard 2003-01-28 04:20:39 UTC
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):

How reproducible:

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.

Additional info:

Comment 1 Ben Woodard 2003-01-28 04:23:43 UTC
objdump --version
GNU objdump 20020207

devi@ben:rpm -q binutils

Comment 2 Jakub Jelinek 2003-02-17 14:54:43 UTC
Can you please attach a sample .s file which shows this?

Comment 3 Ben Woodard 2003-02-18 21:03:54 UTC
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

Comment 4 Jakub Jelinek 2003-02-18 21:17:39 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.