From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3264 invoked by alias); 7 Nov 2004 14:28:27 -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 3115 invoked from network); 7 Nov 2004 14:28:25 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 7 Nov 2004 14:28:25 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iA7ESFHT016926; Sun, 7 Nov 2004 15:28:15 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iA7ESFet003016; Sun, 7 Nov 2004 15:28:15 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iA7ES7Fx003013; Sun, 7 Nov 2004 15:28:07 +0100 (CET) Date: Sun, 07 Nov 2004 15:31:00 -0000 Message-Id: <200411071428.iA7ES7Fx003013@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: gcc@gcc.gnu.org, binutils@sources.redhat.com CC: echristo@redhat.com, seufer@csv.ica.uni-stuttgart.de, gdb@sources.redhat.com Subject: Mixing 32-bit and 64-bit DWARF2/3 sections X-SW-Source: 2004-11/txt/msg00057.txt.bz2 Currently GDB barfs when you use it on an executable that contains compilation units that mix 32-bit and 64-bit DWARF sections. Looking at the (latest?) DWARF3 draft it doesn't seem to be unreasonable that it does so: "The 32-bit and 64-bit DWARF format conventions must not be intermixed within a single compilation unit." The way things are structured now, it is easy to end up with a configuration where this happens since some DWARF sections are generated by GCC and others by gas, i.e. if GCC is configured to generate 32-bit DWARF, and gas will generate 64-bit dwarf. This is currently the case for the (not yet contributed) GCC configuration that's currently used by OpenBSD/mips64. Now this can be easily fixed by changing either the GCC config or gas, but the DWARF3 draft also says: "It is expected that DWARF producing compilers will not use the 64-bit format by default. In most cases, the division of even very large applications into a number of executable and shared objects will suffice to assure that the DWARF sections within each individual linked object are less than 4 GBytes in size. However, for those cases where needed, the 64-format allows the unusual case to be handled as well. Even in this case, it is expected that only application supplied objects will need be compiled using the 64-bit format; separate 32-bit format versions of system supplied shared executable libraries can still be used." This argues that what's currently done in gas and GCC for most 64-bit MIPS targets is wrong, since these use the 64-bit DWARF format unconditionally for the n64 ABI. Fixing this would be a tricky though, since doing it requires some coordination between GCC and binutils. We could add a switch to gas to tell it to generate 64-bit DWARF format. But even then GCC will probably need to support old gas versions that generate 64-bit format by default, adding more config goo to GCC. So I think the existing MIPS targets should probably keep doing what they do now. However, I could make OpenBSD/mips64 do the right thing, making both GCC and gas generate 32-bit DWARF by default. What do the MIPS people think about that? Cheers, Mark P.S. It seems that MIPS is the only 64-bit target for which this is a problem, since all other 64-bit targets (AMD64, UltraSPARC) still use the 32-bit DWARF format.