On 07/11/2016 21:01, Andreas Schwab wrote:
> On Nov 07 2016, Nick Clifton <ni...@redhat.com> 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

_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Reply via email to