From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14413 invoked by alias); 8 Nov 2004 23:03:38 -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 14314 invoked from network); 8 Nov 2004 23:03:27 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 8 Nov 2004 23:03:27 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifixinc.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 33574167EB; Mon, 8 Nov 2004 15:03:27 -0800 (PST) Subject: Re: Mixing 32-bit and 64-bit DWARF2/3 sections From: James E Wilson To: Mark Kettenis Cc: echristo@redhat.com, seufer@csv.ica.uni-stuttgart.de, gdb@sources.redhat.com, gcc@gcc.gnu.org, binutils@sources.redhat.com In-Reply-To: <200411082204.iA8M4jws088177@elgar.sibelius.xs4all.nl> References: <200411071428.iA7ES7Fx003013@elgar.sibelius.xs4all.nl> <418FDD06.9030404@specifixinc.com> <200411082204.iA8M4jws088177@elgar.sibelius.xs4all.nl> Content-Type: text/plain Message-Id: <1099955006.7589.43.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Mon, 08 Nov 2004 23:37:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00066.txt.bz2 On Mon, 2004-11-08 at 14:04, Mark Kettenis wrote: > systems, gas currently generates the new DWARF3 64-bit format. I > merely want to argue that it probably would have been better if the > default had been 32-bit for Linux. It would be reasonable to try to use standard DWARF for non-Irix systems, but the ambiguous SGI DWARF format complicates this. With the SGI DWARF format, you can't tell whether you have 32-bit or 64-bit debug info by looking at the debug info alone. You need external info. Currently, this is based on the ABI. If we have N32 code, then we have 32-bit DWARF always. If we have N64 code, then we have SGI-64-bit DWARF always. (I see that neither bfd nor gdb actually do it this way, but they are supposed to.) In order to change this, we will need some other header flag to indicate whether we are following the SGI scheme or the GNU scheme. If we have an OS field that is set consistently, then we could use that, but I as skeptical whether this is safe in all cases. Not all operating systems have their own OS flags defined, especially for embedded systems. There is also a backwards compatibility problem. That means we need a new flag. We need assembler support to set it, and an assembler directive or option so that gcc can tell the assembler whether or not to set it. So we need an ELF header change, along with gcc, binutils, and gdb patches to deal with it. It isn't clear to me whether the benefits of this change are worth the amount of effort needed to implement it. Anyways, I think it is a reasonable goal, just not sure if it is worth the trouble it will cause. Besides the technical details, you will also need to get political buy in from affected parties for an ABI change, which means mainly the GNU/Linux mips64 folks. I'd suggest that the easiest solution here is to fix gas. Gas should always use dwarf2_format_64bit_irix with the N64 ABI, regardless of whether the target is Irix. This will fix your debugging problems, though it won't give the debug info format you want. Checking, I see that the binutils patch came from here: http://sources.redhat.com/ml/binutils/2003-01/msg00442.html This is a thread with Alexandre Oliva trying to fix some problems with the SGI-64-bit DWARF2 format, and Daniel Jacobowitz questioning why we are using a non-standard format for non-Irix targets, and Alex made this change to try to make Daniel happy. Unfortunately, this causes your current problem, as it makes gas incompatible with gcc. I'd suggest reverting this gas patch to solve your problem as a short term fix. Incidentally, this thread contains some info explaining why Alex thought it was a good idea to be compatible with Irix here, as it made some things easier. The long term fix is a new elf header flag, and gcc, binutils, and gdb changes to set and use it. Reverting the gas patch is far simpler. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com