From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80427 invoked by alias); 23 Oct 2015 07:22:20 -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 80417 invoked by uid 89); 23 Oct 2015 07:22:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 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-f178.google.com Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 23 Oct 2015 07:22:18 +0000 Received: by wicfx6 with SMTP id fx6so18702499wic.1 for ; Fri, 23 Oct 2015 00:22:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.9.2 with SMTP id v2mr2771217wia.24.1445584935700; Fri, 23 Oct 2015 00:22:15 -0700 (PDT) Received: by 10.27.142.215 with HTTP; Fri, 23 Oct 2015 00:22:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2015 07:22:00 -0000 Message-ID: Subject: Re: endianness handling inside gdb From: Ashutosh To: Paul_Koning@dell.com Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-10/txt/msg00094.txt.bz2 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, wrote: > >> On Oct 22, 2015, at 3:01 PM, Ashutosh 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 y= ou're talking about) is built for the byte order being used. A processor c= an only execute code that matches the byte order it's using. Either becaus= e 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 sens= e than, say, trying to debug on an x86 processor using a MIPS binary. > > paul >