From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17114 invoked by alias); 18 May 2006 10:09:17 -0000 Received: (qmail 17098 invoked by uid 22791); 18 May 2006 10:09:16 -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, 18 May 2006 10:09:14 +0000 Received: (qmail 24550 invoked by uid 1010); 18 May 2006 10:09:12 -0000 From: Richard Sandiford To: Mark Mitchell Mail-Followup-To: Mark Mitchell ,fnf@specifix.com, gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, richard@codesourcery.com Cc: fnf@specifix.com, 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> <87y7x9aw12.fsf@talisman.home> <200605171624.16372.fnf@specifix.com> <446B96F9.2070609@codesourcery.com> Date: Thu, 18 May 2006 16:53:00 -0000 In-Reply-To: <446B96F9.2070609@codesourcery.com> (Mark Mitchell's message of "Wed, 17 May 2006 14:34:49 -0700") Message-ID: <87psib3arb.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/msg00399.txt.bz2 Mark Mitchell writes: > Fred Fish wrote: >> On Thursday 11 May 2006 02:57, Richard Sandiford wrote: >>> 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. >> >> Wouldn't that be ELF specific, [...] Yes, but that isn't a problem. MIPS gcc only supports ELF targets these days. >> [...] as well as requiring the linker to >> merge hint strings? I'm a little unclear on just what capabilities >> the current linker has to merge section contents so that "hint >> strings" put into a note section wouldn't be duplicated in the final >> linked output, one for each compilation unit. > > The ARM EABI contains a specification for object-file attributes, > including rules about how to merge them. The specification is quite > general; there are mechanisms for compiler extension, etc. > > It is indeed ELF-specific, but I would guess you could use the same > technique on other object formats that allow additional sections. > > I'm not sure what the current state of support for this feature is in > Binutils, but I think we should consider using the ARM strategy on all > platforms without a previously defined mechanism of their own; we want > it anyhow (for ARM), and we can presumably avoid duplicate effort/code > by reusing the code. I haven't looked at the ARM EABI in detail, but FWIW, that principle sounds good to me too. I agree that it's better to avoid reinventing the wheel. Richard