From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12078 invoked by alias); 1 Dec 2003 15:21:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12010 invoked from network); 1 Dec 2003 15:21:48 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 1 Dec 2003 15:21:48 -0000 Received: by zenia.home (Postfix, from userid 5433) id EEF0120766; Mon, 1 Dec 2003 10:20:38 -0500 (EST) To: fnf@ninemoons.com Cc: gcc-bugs@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: [RFC] Possible gcc/DWARF or gdb/DWARF problem References: <200311292026.hATKQ3OI025805@fred.ninemoons.com> From: Jim Blandy Date: Mon, 01 Dec 2003 15:21:00 -0000 In-Reply-To: <200311292026.hATKQ3OI025805@fred.ninemoons.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-12/txt/msg00003.txt.bz2 Fred Fish writes: > For reference, here are the relevant parts of the dwarfdump output: > > <1>< 107> DW_TAG_base_type > DW_AT_name signed char > DW_AT_byte_size 1 > DW_AT_encoding DW_ATE_signed_char > > <2>< 160> DW_TAG_variable > DW_AT_name l > DW_AT_decl_file 1 /tmp/b.c > DW_AT_decl_line 8 > DW_AT_type <107> > DW_AT_location DW_OP_fbreg 0 > > I'd like to get some comments on whether this is a gcc/DWARF or > gdb/DWARF issue. If the consensus is that gdb is not doing the right > thing, then I'll chase the problem in gdb. If the consensus is that > it is gcc, then I'll file a formal gcc bug report. My guess is that > since gcc is generating the memory offset of a 1 byte object relative > to the frame pointer that the DW_AT_location for the big endian case > should be: > > DW_AT_location DW_OP_fbreg 3 So, in the big-endian case, the compiler is generating code that places the one-byte value at offset 3 from the frame base register. (Since you say the code for the little-endian and big-endian cases is identical, we know it uses 32-bit stores and loads to fb+0 to access it, but that's irrelevant; it's a one-byte value.) Right? You're right --- GCC is wrong. The Dwarf 2 info it's producing clearly describes a one-byte value at offset 0 from the frame base. How GCC decides to generate code to access it is not our problem.