bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/12336] New: [Wishlist] objdump option to use symbol relati


From: johnstul at us dot ibm.com
Subject: [Bug binutils/12336] New: [Wishlist] objdump option to use symbol relative addresses
Date: Tue, 21 Dec 2010 02:27:06 +0000

http://sourceware.org/bugzilla/show_bug.cgi?id=12336

           Summary: [Wishlist] objdump option to use symbol relative
                    addresses
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: binutils
        AssignedTo: address@hidden
        ReportedBy: address@hidden


When using objdump -d, the addresses in the output makes it difficult to use
tools like diff to compare source changes at the asm level.

For instance, if I make a change to some C source, then objdump the compiled .o
file both with and without the change, the resulting diff is filled with
unrelated noise due to the trivial address changes:

-0000000000000900 <lock_hrtimer_base>:
-     900:    55                       push   %rbp
-     901:    48 89 e5                 mov    %rsp,%rbp
-     904:    41 56                    push   %r14
-     906:    41 55                    push   %r13
-     908:    41 54                    push   %r12
-     90a:    53                       push   %rbx
-     90b:    e8 00 00 00 00           callq  910 <lock_hrtimer_base+0x10>
-     910:    49 89 fc                 mov    %rdi,%r12
-     913:    49 89 f5                 mov    %rsi,%r13
-     916:    eb 16                    jmp    92e <lock_hrtimer_base+0x2e>
...
+0000000000000960 <lock_hrtimer_base>:
+     960:    55                       push   %rbp
+     961:    48 89 e5                 mov    %rsp,%rbp
+     964:    41 56                    push   %r14
+     966:    41 55                    push   %r13
+     968:    41 54                    push   %r12
+     96a:    53                       push   %rbx
+     96b:    e8 00 00 00 00           callq  970 <lock_hrtimer_base+0x10>
+     970:    49 89 fc                 mov    %rdi,%r12
+     973:    49 89 f5                 mov    %rsi,%r13
+     976:    eb 16                    jmp    98e <lock_hrtimer_base+0x2e>



It would be much preferable if the objdump output used symbol relative
addresses, and would look something like:
0000000000000960 <lock_hrtimer_base>:
     <+00>:    55                       push   %rbp
     <+01>:    48 89 e5                 mov    %rsp,%rbp
     <+04>:    41 56                    push   %r14
     <+06>:    41 55                    push   %r13
     <+08>:    41 54                    push   %r12
     <+0a>:    53                       push   %rbx
     <+0b>:    e8 00 00 00 00           callq  <lock_hrtimer_base+0x10>
     <+10>:    49 89 fc                 mov    %rdi,%r12
     <+13>:    49 89 f5                 mov    %rsi,%r13
     <+16>:    eb 16                    jmp    <lock_hrtimer_base+0x2e>


And the resulting diff for this function would be:
-0000000000000900 <lock_hrtimer_base>:
+0000000000000960 <lock_hrtimer_base>:

Which makes it obvious that nothing has changed but the start address of the
function.

Using --prefix-address, along with '| cut -d"<" -f2' gets me close to what I
need, but I still get a lot of noise in the call addresses:
-lock_hrtimer_base+0xb> callq  00000000000009f0 
+lock_hrtimer_base+0xb> callq  0000000000000ab0 
 lock_hrtimer_base+0x10> mov    %rdi,%r12
 lock_hrtimer_base+0x13> mov    %rsi,%r13
-lock_hrtimer_base+0x16> jmp    0000000000000a0e 
+lock_hrtimer_base+0x16> jmp    0000000000000ace 
 lock_hrtimer_base+0x18> nopl   0x0(%rax,%rax,1)


Since objdump already provides the <lock_hrtimer_base+0x10> style annotation, I
suspect this wouldn't be very difficult for someone familiar with the code to
implement, and would be very useful!

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]