From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [RFA/ada] Improve is_known_support_routine
Date: Sat, 06 Jan 2007 18:26:00 -0000 [thread overview]
Message-ID: <20070106182652.GR15512@adacore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
Hello,
A customer just reported us an issue that we never noticed before.
It can be reduced to this:
procedure Foo is
begin
raise Constraint_Error;
end Foo;
We're setting an exception catchpoint. Then we debug from a location
that's not where the sources are ("cd subdir"):
% gnatmake -g foo
% gdb foo
(gdb) cd subdir
(gdb) catch exception
(gdb) run
Catchpoint 1, CONSTRAINT_ERROR at <__gnat_raise_nodefer_with_msg>
(e=0x805844c) at a-except.adb:818
818 a-except.adb: No such file or directory.
in a-except.adb
(gdb) f
#0 <__gnat_raise_nodefer_with_msg> (e=0x805844c) at a-except.adb:818
818 in a-except.adb
As you see, the debugger did not go up the call stack to foo.adb.
Here is the the expected output:
(gdb) run
Catchpoint 1, CONSTRAINT_ERROR at 0x080497fe in foo () at foo.adb:3
3 raise Constraint_Error;
(gdb) f
#4 0x080497fe in foo () at foo.adb:3
3 raise Constraint_Error;
The is_known_support_routine identifies any frame for which we cannot
find the source file. The check we currently have in place is a bit too
simplistic, so I replaced it with the function we use to locate source
files:
- if (stat (sal.symtab->filename, &st))
+ if (symtab_to_fullname (sal.symtab) == NULL)
Unfortunately, I cannot reproduce this within our testsuite, because
we use GNAT project files to build the executable. One of the side effects
of using a project file is that the compiler is called with the absolute
filename rather than a relative filename. As a result, symtab->filename
contains the absolute path, and hence the stat call always succeeds.
Because we offer the option of building GDB out of tree, apart from
creating on the fly the setup in a temporary directory, followed by
compiling and then testing there, I am not sure how to create a testcase
for this issue... We were able to add a testcase in our testsuite,
however, as it uses another type of technology that allows us to build
our example programs without project files.
For now, I propose that we commit this patch without adding a testcase.
I think that the symtab_to_fullname routine is already fairly
extensively tested as it just a wrapper around a fairly central routine
in source location.
2007-01-06 Joel Brobecker <brobecker@adacore.com>
* ada-lang.c: Add include of source.h.
(is_known_support_routine): Improve the check verifying that the file
associated to this frame exists.
* Makefile.in (ada-lang.o): Add dependency on source.h.
Tested on x86-linux. Ok to apply?
Thank you,
--
Joel
PS: I'll start working on the other, more cosmetic, improvements for
that routine tomrorrow.
[-- Attachment #2: stat.diff --]
[-- Type: text/plain, Size: 1679 bytes --]
Index: ada-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/ada-lang.c,v
retrieving revision 1.88
diff -u -p -r1.88 ada-lang.c
--- ada-lang.c 4 Jan 2007 06:31:51 -0000 1.88
+++ ada-lang.c 6 Jan 2007 17:28:59 -0000
@@ -55,6 +55,7 @@ Boston, MA 02110-1301, USA. */
#include "exceptions.h"
#include "annotate.h"
#include "valprint.h"
+#include "source.h"
#ifndef ADA_RETAIN_DOTS
#define ADA_RETAIN_DOTS 0
@@ -9072,7 +9073,7 @@ is_known_support_routine (struct frame_i
symbols; in this case, the filename referenced by these symbols
does not exists. */
- if (stat (sal.symtab->filename, &st))
+ if (symtab_to_fullname (sal.symtab) == NULL)
return 1;
for (i = 0; known_runtime_file_name_patterns[i] != NULL; i += 1)
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.870
diff -u -p -r1.870 Makefile.in
--- Makefile.in 4 Jan 2007 22:11:44 -0000 1.870
+++ Makefile.in 6 Jan 2007 17:29:08 -0000
@@ -1696,7 +1696,8 @@ ada-lang.o: ada-lang.c $(defs_h) $(gdb_s
$(inferior_h) $(symfile_h) $(objfiles_h) $(breakpoint_h) \
$(gdbcore_h) $(hashtab_h) $(gdb_obstack_h) $(ada_lang_h) \
$(completer_h) $(gdb_stat_h) $(ui_out_h) $(block_h) $(infcall_h) \
- $(dictionary_h) $(exceptions_h) $(annotate_h) $(valprint_h)
+ $(dictionary_h) $(exceptions_h) $(annotate_h) $(valprint_h) \
+ $(source_h)
ada-typeprint.o: ada-typeprint.c $(defs_h) $(gdb_obstack_h) $(bfd_h) \
$(symtab_h) $(gdbtypes_h) $(expression_h) $(value_h) $(gdbcore_h) \
$(target_h) $(command_h) $(gdbcmd_h) $(language_h) $(demangle_h) \
next reply other threads:[~2007-01-06 18:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-06 18:26 Joel Brobecker [this message]
2007-01-07 7:14 ` Joel Brobecker
2007-01-07 23:38 ` Daniel Jacobowitz
2007-01-08 3:30 ` Joel Brobecker
2007-01-08 3:30 ` Joel Brobecker
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=20070106182652.GR15512@adacore.com \
--to=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