[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible bug in objdump
From: |
Nick Clifton |
Subject: |
Re: Possible bug in objdump |
Date: |
Thu, 11 Jun 2020 10:41:30 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
Hi Joe,
> The possible bug is explained in the comments near the beginning of the file
> Bug.c
Please could file a bug report using the binutils Bugzilla system here:
https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
When you do, it would be really helpful if you could include a copy of the
"Bug" executable, as well as the other files, as it is very hard to ensure
that we have exactly the same compilation environment as you have.
As to the the bug itself:
// 99f: 48 8b 05 8a 52 20 00 mov rax,QWORD PTR [rip+0x20528a]
# 205c30 <XtStrings+0x48f0>
//
// The instructions access XtStrings+0x48f0. However, if you look at Bug.elf
you see
//
// 11: 0000000000201340 2649 OBJECT GLOBAL DEFAULT 21 XtStrings
//
// The size of XtStrings is 2649 decimal. But XtStrings+0x48f0 is beyond the
region occupied by XtStrings.
My guess is that the disassembler has chosen XtStrings as being the
nearest user-visible symbol to the address referenced, in the hopes
that it might be useful to the reader. The disassembler is not saying
that the XtStrings array is actually being used, but merely that it
could find any closer symbol.
Cheers
Nick
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Possible bug in objdump,
Nick Clifton <=