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

Summary: objdump calculates the offset after ud2a wrong on i386
Product: [Retired] Red Hat Linux Reporter: Ben Woodard <woodard>
Component: binutilsAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-02-18 21:17:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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:
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-28 04:23:43 UTC
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 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
problem.

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
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.