This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/ada] Improve is_known_support_routine


I noticed while cleaning up the same code that I forgot to delete
a local variable that became unused.  Here is a new patch.
Rested on x86-linux.

> 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

Attachment: stat.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]