This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: endianness handling inside gdb
- From: Gary Benson <gbenson at redhat dot com>
- To: Ashutosh <ashutoshpal2006 at gmail dot com>
- Cc: Paul_Koning at dell dot com, gdb at sourceware dot org
- Date: Fri, 23 Oct 2015 12:55:55 +0100
- 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> <CADHm+zu_1JnfrLWyXxAPeZh4APDtC6buRbBVMnLG==mtVK3VSw at mail dot gmail dot com>
Ashutosh wrote:
> 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
...
> Thinking again about this now, the scenario that I mention looks
> somewhat uncommon (and may be digressing a bit from the ELF
> standard)
It probably is a violation of the standard. Page 1-6 says that
e_ident[EI_DATA] specifies the data encoding of the processor-
specific data in the object file. In the file you describe this
is not the case.
Is there some special reason why this ELF file is like this?
What generated the file?
Thanks,
Gary
--
http://gbenson.net/