From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119013 invoked by alias); 23 Oct 2015 11:56:01 -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 119001 invoked by uid 89); 23 Oct 2015 11:55:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 23 Oct 2015 11:55:59 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id CB3378C1B8; Fri, 23 Oct 2015 11:55:57 +0000 (UTC) Received: from blade.nx (ovpn-116-101.ams2.redhat.com [10.36.116.101]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9NBtvp9014429; Fri, 23 Oct 2015 07:55:57 -0400 Received: by blade.nx (Postfix, from userid 1000) id E0A3E264568; Fri, 23 Oct 2015 12:55:55 +0100 (BST) Date: Fri, 23 Oct 2015 11:56:00 -0000 From: Gary Benson To: Ashutosh Cc: Paul_Koning@dell.com, gdb@sourceware.org Subject: Re: endianness handling inside gdb Message-ID: <20151023115555.GA1584@blade.nx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00095.txt.bz2 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/