From: Fred Fish <fnf@specifix.com>
To: gcc-patches@gcc.gnu.org
Cc: gdb-patches@sourceware.org
Subject: [RFC] Passing MIPS debug hints between gcc and gdb
Date: Wed, 10 May 2006 16:05:00 -0000 [thread overview]
Message-ID: <200605101206.01433.fnf@specifix.com> (raw)
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");
next reply other threads:[~2006-05-10 16:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 16:05 Fred Fish [this message]
2006-05-11 6:57 ` Richard Sandiford
2006-05-11 10:16 ` Fred Fish
2006-05-17 20:32 ` Fred Fish
2006-05-18 0:04 ` Mark Mitchell
2006-05-18 16:53 ` Richard Sandiford
2006-06-12 10:10 ` Fred Fish
2006-06-12 11:07 ` Richard Sandiford
2006-06-13 16:08 ` Fred Fish
2006-06-13 17:42 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200605101206.01433.fnf@specifix.com \
--to=fnf@specifix.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox