Re: endianness handling inside gdb

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,  <[email protected]> wrote:
>
>> On Oct 22, 2015, at 3:01 PM, Ashutosh <[email protected]> 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
>