From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128959 invoked by alias); 22 Oct 2015 19:01:55 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 128942 invoked by uid 89); 22 Oct 2015 19:01:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f180.google.com Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com) (209.85.212.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 22 Oct 2015 19:01:53 +0000 Received: by wicfx6 with SMTP id fx6so2057710wic.1 for ; Thu, 22 Oct 2015 12:01:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.92.170 with SMTP id cn10mr141850wjb.12.1445540510733; Thu, 22 Oct 2015 12:01:50 -0700 (PDT) Received: by 10.27.142.215 with HTTP; Thu, 22 Oct 2015 12:01:50 -0700 (PDT) Date: Thu, 22 Oct 2015 19:01:00 -0000 Message-ID: Subject: endianness handling inside gdb From: Ashutosh To: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-10/txt/msg00092.txt.bz2 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