This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

endianness handling inside gdb


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]