* [patch, mips, stabs] Do any MIPS targets use stabs?
@ 2013-01-07 18:27 Steve Ellcey
2013-01-07 20:30 ` Richard Sandiford
0 siblings, 1 reply; 6+ messages in thread
From: Steve Ellcey @ 2013-01-07 18:27 UTC (permalink / raw)
To: gcc-patches
While testing all the variations of my mips-mti-elf target I found that
a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
using a stabs debug flag (-gstabs3 for example) and -mips16. While running
the GNU simulator I get:
mips-core: 1 byte read to unmapped address 0xffffe820 at 0xffffffff80020278
program stopped with signal 10 (User defined signal 1).
FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test
Since I don't actually care about STABS I was looking at undefining
DBX_DEBUGGING_INFO in mips-mti-elf.h and mips-mti-linux.h which makes
the failures a moot point for me since I would no longer run the tests
with any -stabs flags.
But I was wondering, are there any MIPS targets that do use stabs? If not
maybe we should just remove the define of DBX_DEBUGGING_INFO from mips.h
instead of undefing it just for my targets. Opinions?
I saw the discussion about removing STABS completely from GCC, etc. but it
looks like there is still some users who want it on some targets.
Here is my default patch which just undef's it for the mti targets.
Steve Ellcey
sellcey@mips.com
2013-01-07 Steve Ellcey <sellcey@mips.com>
* config/mips/mips-mti-elf.h: undef DBX_DEBUGGING_INFO.
* config/mips/mips-mti-linux.h: Ditto.
diff --git a/gcc/config/mips/mti-elf.h b/gcc/config/mips/mti-elf.h
index f6b38a5..f90b060 100644
--- a/gcc/config/mips/mti-elf.h
+++ b/gcc/config/mips/mti-elf.h
@@ -41,3 +41,6 @@ along with GCC; see the file COPYING3. If not see
\
/* Configuration-independent MIPS rules. */ \
BASE_DRIVER_SELF_SPECS
+
+
+#undef DBX_DEBUGGING_INFO
diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
index cda9bdc..c12138f 100644
--- a/gcc/config/mips/mti-linux.h
+++ b/gcc/config/mips/mti-linux.h
@@ -45,3 +45,5 @@ along with GCC; see the file COPYING3. If not see
\
/* Use the standard linux specs for everything else. */ \
LINUX64_DRIVER_SELF_SPECS
+
+#undef DBX_DEBUGGING_INFO
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch, mips, stabs] Do any MIPS targets use stabs?
2013-01-07 18:27 [patch, mips, stabs] Do any MIPS targets use stabs? Steve Ellcey
@ 2013-01-07 20:30 ` Richard Sandiford
2013-01-07 20:38 ` Richard Sandiford
2013-01-07 20:41 ` Steve Ellcey
0 siblings, 2 replies; 6+ messages in thread
From: Richard Sandiford @ 2013-01-07 20:30 UTC (permalink / raw)
To: Steve Ellcey ; +Cc: gcc-patches
"Steve Ellcey " <sellcey@mips.com> writes:
> While testing all the variations of my mips-mti-elf target I found that
> a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
> using a stabs debug flag (-gstabs3 for example) and -mips16. While running
> the GNU simulator I get:
>
> mips-core: 1 byte read to unmapped address 0xffffe820 at 0xffffffff80020278
> program stopped with signal 10 (User defined signal 1).
> FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test
>
> Since I don't actually care about STABS I was looking at undefining
> DBX_DEBUGGING_INFO in mips-mti-elf.h and mips-mti-linux.h which makes
> the failures a moot point for me since I would no longer run the tests
> with any -stabs flags.
>
> But I was wondering, are there any MIPS targets that do use stabs? If not
> maybe we should just remove the define of DBX_DEBUGGING_INFO from mips.h
> instead of undefing it just for my targets. Opinions?
Do you know why selecting stabs causes an execution failure?
That shouldn't happen regardless of whether the debug info itself is good.
I don't mind removing stabs from all MIPS targets, but I'd like to
understand why we get the execution failure first.
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch, mips, stabs] Do any MIPS targets use stabs?
2013-01-07 20:30 ` Richard Sandiford
@ 2013-01-07 20:38 ` Richard Sandiford
2013-01-07 20:54 ` Steve Ellcey
2013-01-07 20:41 ` Steve Ellcey
1 sibling, 1 reply; 6+ messages in thread
From: Richard Sandiford @ 2013-01-07 20:38 UTC (permalink / raw)
To: Steve Ellcey ; +Cc: gcc-patches
Richard Sandiford <rdsandiford@googlemail.com> writes:
> "Steve Ellcey " <sellcey@mips.com> writes:
>> While testing all the variations of my mips-mti-elf target I found that
>> a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
>> using a stabs debug flag (-gstabs3 for example) and -mips16. While running
>> the GNU simulator I get:
>>
>> mips-core: 1 byte read to unmapped address 0xffffe820 at 0xffffffff80020278
>> program stopped with signal 10 (User defined signal 1).
>> FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test
>>
>> Since I don't actually care about STABS I was looking at undefining
>> DBX_DEBUGGING_INFO in mips-mti-elf.h and mips-mti-linux.h which makes
>> the failures a moot point for me since I would no longer run the tests
>> with any -stabs flags.
>>
>> But I was wondering, are there any MIPS targets that do use stabs? If not
>> maybe we should just remove the define of DBX_DEBUGGING_INFO from mips.h
>> instead of undefing it just for my targets. Opinions?
>
> Do you know why selecting stabs causes an execution failure?
> That shouldn't happen regardless of whether the debug info itself is good.
Ah, sorry, this reminded me of a patch I'd written a year ago and never
got around to sanity-checking. Does it fix the problem for you?
Richard
Index: gas/config/tc-mips.c
===================================================================
--- gas/config/tc-mips.c 2012-01-28 14:47:10.000000000 +0000
+++ gas/config/tc-mips.c 2012-01-28 14:48:14.000000000 +0000
@@ -1476,7 +1476,9 @@ static const pseudo_typeS mips_pseudo_ta
{"section", s_change_section, 0},
{"short", s_cons, 1},
{"single", s_float_cons, 'f'},
+ {"stabd", s_mips_stab, 'd'},
{"stabn", s_mips_stab, 'n'},
+ {"stabs", s_mips_stab, 's'},
{"text", s_change_sec, 't'},
{"word", s_cons, 2},
@@ -16817,9 +16819,7 @@ s_insn (int ignore ATTRIBUTE_UNUSED)
static void
s_mips_stab (int type)
{
- if (type == 'n')
- mips_mark_labels ();
-
+ mips_mark_labels ();
s_stab (type);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch, mips, stabs] Do any MIPS targets use stabs?
2013-01-07 20:30 ` Richard Sandiford
2013-01-07 20:38 ` Richard Sandiford
@ 2013-01-07 20:41 ` Steve Ellcey
1 sibling, 0 replies; 6+ messages in thread
From: Steve Ellcey @ 2013-01-07 20:41 UTC (permalink / raw)
To: Richard Sandiford; +Cc: gcc-patches
On Mon, 2013-01-07 at 20:30 +0000, Richard Sandiford wrote:
> "Steve Ellcey " <sellcey@mips.com> writes:
> > While testing all the variations of my mips-mti-elf target I found that
> > a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
> > using a stabs debug flag (-gstabs3 for example) and -mips16. While running
> > the GNU simulator I get:
> >
> > mips-core: 1 byte read to unmapped address 0xffffe820 at 0xffffffff80020278
> > program stopped with signal 10 (User defined signal 1).
> > FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test
>
> Do you know why selecting stabs causes an execution failure?
> That shouldn't happen regardless of whether the debug info itself is good.
>
> I don't mind removing stabs from all MIPS targets, but I'd like to
> understand why we get the execution failure first.
>
> Richard
No, I don't know why I get the execution failure. I dug around a bit
but could not figure out what or where the problem was coming from. I
assume the executable is accessing a bad address or an uninitialized bit
of memory somewhere but I could not figure out where. The actual
executable code is the same with or without the debug information. I
don't even know if this is a bug in GCC or in the GNU simulator. My
inability to figure out where the problem was occurring is the main
reason I started wondering why I even cared about stabs.
Steve Ellcey
sellcey@mips.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch, mips, stabs] Do any MIPS targets use stabs?
2013-01-07 20:38 ` Richard Sandiford
@ 2013-01-07 20:54 ` Steve Ellcey
2013-01-08 16:30 ` Steve Ellcey
0 siblings, 1 reply; 6+ messages in thread
From: Steve Ellcey @ 2013-01-07 20:54 UTC (permalink / raw)
To: Richard Sandiford; +Cc: gcc-patches
On Mon, 2013-01-07 at 20:38 +0000, Richard Sandiford wrote:
>
> Ah, sorry, this reminded me of a patch I'd written a year ago and never
> got around to sanity-checking. Does it fix the problem for you?
>
> Richard
It fixes my small test case, I will try it on the full testsuite
overnight.
Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch, mips, stabs] Do any MIPS targets use stabs?
2013-01-07 20:54 ` Steve Ellcey
@ 2013-01-08 16:30 ` Steve Ellcey
0 siblings, 0 replies; 6+ messages in thread
From: Steve Ellcey @ 2013-01-08 16:30 UTC (permalink / raw)
To: Richard Sandiford; +Cc: gcc-patches
On Mon, 2013-01-07 at 12:54 -0800, Steve Ellcey wrote:
> On Mon, 2013-01-07 at 20:38 +0000, Richard Sandiford wrote:
>
> >
> > Ah, sorry, this reminded me of a patch I'd written a year ago and never
> > got around to sanity-checking. Does it fix the problem for you?
> >
> > Richard
>
> It fixes my small test case, I will try it on the full testsuite
> overnight.
>
> Steve
The full testsuite worked fine too, so I think this should be checked
in. Given this fix I will probably leave the stab support alone for
now, though I would have no objection if someone wanted to remove it for
MIPS.
Steve Ellcey
sellcey@mips.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-01-08 16:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-07 18:27 [patch, mips, stabs] Do any MIPS targets use stabs? Steve Ellcey
2013-01-07 20:30 ` Richard Sandiford
2013-01-07 20:38 ` Richard Sandiford
2013-01-07 20:54 ` Steve Ellcey
2013-01-08 16:30 ` Steve Ellcey
2013-01-07 20:41 ` Steve Ellcey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).