This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: endianness handling inside gdb
- From: Ashutosh <ashutoshpal2006 at gmail dot com>
- To: Paul_Koning at dell dot com
- Cc: gdb at sourceware dot org
- Date: Fri, 23 Oct 2015 12:52:15 +0530
- Subject: Re: endianness handling inside gdb
- Authentication-results: sourceware.org; auth=none
- References: <CADHm+zuob2dZcrxqoRXOmOkwGqq8cJinaTYMwv60kAfD10sqsw at mail dot gmail dot com> <A619260E-0459-49FC-B318-1BBE778BA31B at dell dot com>
Hi paul,
Actually, the ELF that I am dealing with, organizes the data in the
following way:
- all values inside non-allocatable/non-loadable sections like the
dwarf sections are encoded as per the endianness of the ELF
- all the processor-specific (i.e. all loadable) values are encoded as
per the endianness of the target processor
Since all the processor-specific data (code + data sections) are
encoded as per processor's endianness, it will execute fine on it.
But, gdb will interpret the dwarf values incorrectly because it is
using the processor's endianness for the same (as shown in the
code-snippets in the original mail)
Thinking again about this now, the scenario that I mention looks
somewhat uncommon (and may be digressing a bit from the ELF standard);
and probably that's why it's not considered inside Gdb. So for now, I
will proceed further by adapting the dwarf-reader in the gdb code and
keep it locally.
Thanks for your reply.
Regards,
ash
On Fri, Oct 23, 2015 at 12:53 AM, <Paul_Koning@dell.com> wrote:
>
>> On Oct 22, 2015, at 3:01 PM, Ashutosh <ashutoshpal2006@gmail.com> wrote:
>>
>> Hi Experts,
>>
>> Does gdb handles the case where endianness of the ELF file is
>> different from the endianness of the target processor?
>
> That doesn't make any sense. The executable file (I assume that's what you're talking about) is built for the byte order being used. A processor can only execute code that matches the byte order it's using. Either because that's the way the processor is configured, or because it has selectable order and this particular process has selected that order. But a mismatch between processor and executable file byte order doesn't make any more sense than, say, trying to debug on an x86 processor using a MIPS binary.
>
> paul
>