Bug 82886 - objdump calculates the offset after ud2a wrong on i386
objdump calculates the offset after ud2a wrong on i386
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: binutils (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-27 23:20 EST by Ben Woodard
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-18 16:17:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Woodard 2003-01-27 23:20:39 EST
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:
Always

Steps to Reproduce:
1. build a kernel
2. disassemble it.
3.
    

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-27 23:23:43 EST
objdump --version
GNU objdump 2.11.93.0.2 20020207

devi@ben:rpm -q binutils
binutils-2.11.93.0.2-11
Comment 2 Jakub Jelinek 2003-02-17 09:54:43 EST
Can you please attach a sample .s file which shows this?
Comment 3 Ben Woodard 2003-02-18 16:03:54 EST
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
problem.
Comment 4 Jakub Jelinek 2003-02-18 16:17:39 EST
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
instructions.
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.