bug-binutils
[Top][All Lists]
Advanced

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

Re: objdump '--stop-address' option stop on a wrong ending address


From: BERBAR Florian
Subject: Re: objdump '--stop-address' option stop on a wrong ending address
Date: Mon, 7 Nov 2016 22:24:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0

On 07/11/2016 21:01, Andreas Schwab wrote:
> On Nov 07 2016, Nick Clifton <address@hidden> wrote:
> 
>> Hi Florian,
>>
>>> I try to extract function assembly code with objdump using
>>> "--start-address" and "--stop-address" options but the stop address stop
>>> on the second to last address.
>>
>>> $ objdump --start-address=0x50c40 --stop-address=0x50c5f -d
>>
>>>    50c59:   b8 01 00 00 00          mov    $0x1,%eax
>>>    50c5e:   c3                      retq
>>>
>>> As you can see the last address is wrong. The assembly code stop on
>>> 0x50c5e instead of 0x50c5f.
>>
>> Actually this is the intended behaviour.  The --stop-address option 
>> specifies the address at which objdump should *stop* displaying data.  
>> So when objdump reaches address 50c5f it stops and does not display
>> the disassembly for that address.
>>
>> In order to display the entire disassembly of a specific region you
>> need to set the stop address to one more than the last address of the
>> region concerned.
> 
> But note that the region does end at 0x50c5f, so there is nothing more
> to disassemble anyway.

If we take a look to the whole assembly code of the "printf_size_info"
functon. We can see à "nop" mnemonics at 0x50c5f before the next
function. This was originally doubt about the "--stop-address" option
dysfunction.

0000000000050c40 <printf_size_info@@GLIBC_2.2.5>:
   50c40:       48 85 f6                test   %rsi,%rsi
   50c43:       74 14                   je     50c59 <printf_size_info@@GLIBC_2.
2.5+0x19>
   50c45:       0f b6 47 0c             movzbl 0xc(%rdi),%eax
   50c49:       83 e0 01                and    $0x1,%eax
   50c4c:       3c 01                   cmp    $0x1,%al
   50c4e:       19 c0                   sbb    %eax,%eax
   50c50:       30 c0                   xor    %al,%al
   50c52:       05 07 01 00 00          add    $0x107,%eax
   50c57:       89 02                   mov    %eax,(%rdx)
   50c59:       b8 01 00 00 00          mov    $0x1,%eax
   50c5e:       c3                      retq
   50c5f:       90                      nop

But you're right Andreas. The "no operation" opcode can be skip. It
doesn't raise a problem against the meaning of this function. Moreover
the fully respect of the symbol definition seams to relate to a size of
0x1f (31 opcodes).

In this case the function with the "nop" opcode te function is 0x20 long
(32 opcodes).

This "nop" opcode seams to be some padding added during the compilation
process.

> 
> Andreas.
> 

Thank you for this advice.

Florian

Attachment: 0x346BBA8F.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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