endianness handling inside gdb

endianness handling inside gdb

[Ashutosh]

Hi Experts,

Does gdb handles the case where endianness of the ELF file is
different from the endianness of the target processor? I noticed the
following code inside dwarf2loc.c:

const gdb_byte * dwarf2_find_location_expression (struct
dwarf2_loclist_baton *baton,
         size_t *locexpr_length, CORE_ADDR pc)
{
  struct objfile *objfile = dwarf2_per_cu_objfile (baton->per_cu);
  struct gdbarch *gdbarch = get_objfile_arch (objfile);
  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
...
}

The above function is used to reach to the location-expression in the
location-list inside the dwarf information. In the process, it reads
the addresses in the location list and for that it makes use of the
endianness (see the calls to extract_unsigned_integer inside function
decode_debug_loc_addresses)
But, the endianness used here is that of the target (queried from
gdbarch API) instead of the ELF (BFD API)
I would use something like:
byte_order = bfd_big_endian (objfile->obfd) ? BFD_ENDIAN_BIG :
BFD_ENDIAN_LITTLE;
to get the endianness from the ELF.

In my case, the endianness in ELF is different from that of the target
core and with above code, gdb ends up computing wrong values from
dwarf information.

My question is: Does gdb assumes that the endianness of the target
processor and the ELF should be same or the above code is sort of a
bug?

Thanks,
ash

Re: endianness handling inside gdb

[Paul_Koning]

> 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

Re: endianness handling inside gdb

[Ashutosh]

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
>

Re: endianness handling inside gdb

[Gary Benson]

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/