From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16793 invoked by alias); 10 May 2006 16:05:30 -0000 Received: (qmail 16368 invoked by uid 22791); 10 May 2006 16:05:28 -0000 X-Spam-Check-By: sourceware.org Received: from w099.z064220152.sjc-ca.dsl.cnc.net (HELO duck.specifix.com) (64.220.152.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 May 2006 16:05:23 +0000 Received: from [::1] (duck.specifix.com [64.220.152.99]) by duck.specifix.com (Postfix) with ESMTP id D23E3FC5C; Wed, 10 May 2006 09:05:20 -0700 (PDT) From: Fred Fish Reply-To: fnf@specifix.com To: gcc-patches@gcc.gnu.org Subject: [RFC] Passing MIPS debug hints between gcc and gdb Date: Wed, 10 May 2006 16:05:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605101206.01433.fnf@specifix.com> 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/msg00194.txt.bz2 Since this issue affects both gcc and gdb I'm posting this to both lists. 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. 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. 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. 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. Below is a patch I'm successfully using in gcc. There is a matching patch for gdb to make use of the new sections. There is also a patch for newlib and binutils to prevent the sections from being deleted by the linker. Does anyone have any suggestions for a better way to pass these debugging hints to gdb? -Fred Index: mips.c =================================================================== RCS file: /cvsroots/latest/src/gcc/gcc/config/mips/mips.c,v retrieving revision 1.1.1.8 diff -r1.1.1.8 mips.c 5798,5803c5798,5810 < /* There is no ELF header flag to distinguish long32 forms of the < EABI from long64 forms. Emit a special section to help tools < such as GDB. */ < if (mips_abi == ABI_EABI) < fprintf (asm_out_file, "\t.section .gcc_compiled_long%d\n", < TARGET_LONG64 ? 64 : 32); --- > /* The -mlong32 and -mlong64 options can be used with any ABI, and may > also affect the pointer size. There is no ELF header flag to specify > how many bits longs and pointers have. Emit special sections to help > tools such as GDB. Also, -msoft-float can be used even when the > architecture supports hardware floats, and GDB needs to know about so > it can do the right thing when calling functions by hand. */ > > fprintf (asm_out_file, "\t.section .gcc_compiled_long%d\n", > TARGET_LONG64 ? 64 : 32); > fprintf (asm_out_file, "\t.section .gcc_compiled_pointer%d\n", > POINTER_SIZE); > fprintf (asm_out_file, "\t.section .gcc_compiled_%sfloat\n", > TARGET_SOFT_FLOAT ? "soft" : "hard");