From: Pedro Alves <pedro@codesourcery.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA v2] valprint.c / *-valprint.c: Don't lose `embedded_offset'
Date: Mon, 24 Jan 2011 19:39:00 -0000 [thread overview]
Message-ID: <201101241910.55018.pedro@codesourcery.com> (raw)
In-Reply-To: <20110124165624.GA2413@adacore.com>
On Monday 24 January 2011 16:56:24, Joel Brobecker wrote:
> > > Joel, there are Ada changes in the patch, are those okay?
>
> Hi Pedro. The changes look sane to me. There was only one place where
> the offset was missing, affecting packed records. Patch attached.
Thank you! I've committed the patch with that change in.
> I wish we could allow everyone to get a clean run in gdb.ada,
> it really sucks :-(.
Yeah... :-(
> I tried to speed things up a bit on the compiler
> side with the descriptive-type stuff, but it's very very hard to get
> feedback from maintainers who have the power to approve or make
> suggestions... I need to check with Olivier, but he might have given
> up on it :-(.
Ah, so you're saying that most of the failures we get with FSF
gnat are related to some sort descriptive-type debug info support
or something like that, I guess?
Here's the current set of Ada fails I get:
FAIL: gdb.ada/array_bounds.exp: print table'first
FAIL: gdb.ada/array_bounds.exp: print table'last
FAIL: gdb.ada/arrayidx.exp: print e_one_two_three, indexes off
FAIL: gdb.ada/arrayidx.exp: print r_two_three, indexes off
FAIL: gdb.ada/arrayidx.exp: print e_one_two_three
FAIL: gdb.ada/arrayidx.exp: print r_two_three
FAIL: gdb.ada/catch_ex.exp: insert catchpoint on all Ada exceptions
FAIL: gdb.ada/catch_ex.exp: info break, catch all Ada exceptions
FAIL: gdb.ada/catch_ex.exp: continuing to first exception (the program exited)
FAIL: gdb.ada/catch_ex.exp: continuing to second exception (the program is no
longer running)
FAIL: gdb.ada/catch_ex.exp: insert catchpoint on Program_Error
FAIL: gdb.ada/catch_ex.exp: insert catchpoint on failed assertions
FAIL: gdb.ada/catch_ex.exp: insert catchpoint on unhandled exceptions
FAIL: gdb.ada/catch_ex.exp: info break, second run
FAIL: gdb.ada/catch_ex.exp: continuing to Program_Error exception (the
program exited)
FAIL: gdb.ada/catch_ex.exp: continuing to failed assertion (the program is no
longer running)
FAIL: gdb.ada/catch_ex.exp: continuing to unhandled exception (the program is
no longer running)
FAIL: gdb.ada/catch_ex.exp: continuing to program completion (the program is
no longer running)
FAIL: gdb.ada/dyn_loc.exp: info locals
XFAIL: gdb.ada/null_array.exp: print my_table
FAIL: gdb.ada/null_array.exp: ptype my_table
FAIL: gdb.ada/packed_tagged.exp: print x
FAIL: gdb.ada/taft_type.exp: print w.e.all
Many of the failures look indeed related to something not
mapping integers to descriptive names (somewhat like
enums)? I'm clueless about Ada...
Maybe we could catch these cases and KFAIL them instead of
FAILing?
Looking at the log of a couple of odd ones:
(gdb) catch exception
Cannot insert catchpoints in this configuration.
(gdb) FAIL: gdb.ada/catch_ex.exp: insert catchpoint on all Ada exceptions
info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000401495 in main at
/home/pedro/gdb/tdd_upstream/build/gdb/testsuite/gdb.ada/catch_ex/b~foo.adb:110
breakpoint already hit 1 time
(gdb) FAIL: gdb.ada/catch_ex.exp: info break, catch all Ada exceptions
continue
Continuing.
raised CONSTRAINT_ERROR : foo.adb:41 explicit raise
Program exited with code 01.
(gdb) FAIL: gdb.ada/catch_ex.exp: continuing to first exception (the program
exited)
continue
The program is not being run.
(gdb) FAIL: gdb.ada/catch_ex.exp: continuing to second exception (the program
is no longer running)
(and other similar cascaded FAILs). Maybe we should handle the
missing support gracefully, and bail out unsupported?
And this one:
Breakpoint 1, p () at
/home/pedro/gdb/tdd_upstream/src/gdb/testsuite/gdb.ada/taft_type/p.adb:22
22 end P; -- START
(gdb) print w.e.all
No definition of "w.e" in current context.
(gdb) FAIL: gdb.ada/taft_type.exp: print w.e.all
Maybe a test bug?
--
Pedro Alves
next prev parent reply other threads:[~2011-01-24 19:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 13:24 Pedro Alves
2011-01-24 16:56 ` Pedro Alves
2011-01-24 17:37 ` Joel Brobecker
2011-01-24 19:39 ` Pedro Alves [this message]
2011-01-24 19:46 ` Pedro Alves
2011-01-24 21:06 ` Joel Brobecker
2011-01-24 19:47 ` Pedro Alves
2011-01-28 11:35 ` Tom Tromey
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=201101241910.55018.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=brobecker@adacore.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).