From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5753 invoked by alias); 11 May 2006 06:57:36 -0000 Received: (qmail 5738 invoked by uid 22791); 11 May 2006 06:57:35 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 06:57:33 +0000 Received: (qmail 19257 invoked by uid 1010); 11 May 2006 06:57:32 -0000 From: Richard Sandiford To: fnf@specifix.com Mail-Followup-To: fnf@specifix.com,gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, richard@codesourcery.com Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org Subject: Re: [RFC] Passing MIPS debug hints between gcc and gdb References: <200605101206.01433.fnf@specifix.com> Date: Thu, 11 May 2006 06:57:00 -0000 In-Reply-To: <200605101206.01433.fnf@specifix.com> (Fred Fish's message of "Wed, 10 May 2006 12:06:01 -0400") Message-ID: <87y7x9aw12.fsf@talisman.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00208.txt.bz2 Fred Fish writes: > Currently gcc supports generating two zero content sections, the names > of which are supposed to be used by gdb. > > One specifies the ABI, is of the form ".mdebug.abiXX", and gdb does > currently look for it. > > Another has a name of the form ".gcc_compiled_longXX" and gdb does not > currently look for it. Ah. Presumably the patch to do that was never contributed then. It does exist somewhere! > This is supposed to handle the case where gcc has been given the > command line option -mlong32 or -mlong64. Since these can be used > independently of the ABI, the current gcc code should be changed to > always generate this section. Right. > However, the size of pointers can also be affected by -mlongXX. In > theory we can figure out how the pointer size is affected by knowing > the ABI and other stuff, but it's much simplier to just let gcc > specify it the same way as the size of longs. You're right: the size of everything is determined by the combination of the ABI "name" and long size. The gdb patch I mentioned did do that IIRC. (I didn't write that patch myself, and my memory's hazy.) It was certainly the intention that gdb work this out for itself. > I have found, from chasing other MIPS gdb testsuite failures, that gdb > also needs to know when code has been compiled with soft float, on > hardware that supports hard float, so that it can call functions by > hand with float arguments in the right location. So we need another > section for that. > > Just to complicate things, the latest development binutils linker > removes sections with no contents, so all of these disappear in the > output file. Using empty sections was always a hack, to be honest (modelled on the old .gcc_compiled_v3 thing, whatever it was called). I suppose we should be using note sections really. You didn't mention it, but your patch removes the EABI conditional above the .gcc_compiled_long* code. I'm not comfortable with adding the sections unconditionally though. It may confuse IRIX. As far as I'm concerned, EABI is the only ABI where we support both -mlong32 and -mlong64. ISTR someone deciding to use -mabi=o64 -mlong64 as well. Since both EABI and o64 are basically GNU inventions, I'd be OK with relaxing the condition to EABI || o64 if it's o64 you need this for. I suppose we should make the incorrect -mlong* option an error for other ABIs. (Another one for the TODO list.) Richard