This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada
- From: Daniel Jacobowitz <drow at false dot org>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 5 Mar 2004 11:48:15 -0500
- Subject: Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada
- References: <20040224195615.GC542@gnat.com> <20040224230812.GE542@gnat.com> <20040225183211.GH1105@gnat.com> <20040225201749.GA21911@nevyn.them.org> <20040226223742.GH1154@gnat.com> <20040226230239.GA8487@nevyn.them.org> <20040303042107.GB1146@gnat.com> <20040305041814.GI5320@nevyn.them.org> <20040305060322.GD1226@gnat.com>
On Thu, Mar 04, 2004 at 10:03:22PM -0800, Joel Brobecker wrote:
> Thank you very much for your very helpful comments, Daniel!
>
> > OK; any interest in breaking out the language-independent bits of this
> > feature for review and discussion? While it's pretty uninteresting for
> > C/C++, it should work there. For Java and Fortran this could be
> > useful, since they also have the concept of a main program. At least
> > GCJ does, I'm not sure about Java in general.
>
> Sure. I'll make a note of starting a new thread about this. I think it
> will be useful even in C. Using "begin" is shorter than doing "tbreak
> main; run" (although one can use a user-defined function, true).
>
> > By the way, there's a problem with gdb_begin: it can only be used once
> > because it counts as a PASS/FAIL with a specific hardcoded name. It
> > should either not be a test, or more likely, should have a unique name.
>
> True (but one could argue that runto_main has the same problem, right? :-)
No. Take a look at the implementation of runto; it does not issue a
PASS if it messes up. It does issue a fixed fail message but the
expectation is that you'll bail out of the test script if that happens.
> We can add an extra optional parameter (to be used only when this
> function is used more than once in a given testcase), but...
>
> > At that point, why have a procedure for it? You're just passing its
> > arguments to gdb_test.
>
> ... that would not be necessary if we decide that it's not worth
> creating this new function. Indeed, it is just as simple to call
> gdb_test directly. Except that I just remembered that there are cases
> where we will need to pass an argument to the begin command [1].
>
> I know of only one system (VxWorks) where this is extra parameter
> is necessary. On this system, and with GNAT, the extra parameter is
> identical to the name of the executable (ie we've decided that the entry
> point name would be identical to the name of main procedure). So I
> think we eventually want gdb_begin to be intelligent enough to compute
> the name of the entry-point, and then fill in the extra parameter
> automatically. I haven't thought this through yet, but I see one way of
> doing it:
>
> proc gdb_begin {entry_point expected_output opt_id} {
> set begin_command "begin"
>
> if [is_remote host] {
> if [istarget "*-*-vxworks*"] {
> # The VxWorks debugger requires that we provide the name of
> # the entry-point in the module we want to debug.
> set begin_command "$begin_command $entry_point"
> }
> }
>
> gdb_test "begin $entry_point" "$expected_output" "begin command $opt_id"
> }
>
> As I don't see any supported platform where this would be necessary yet,
> I simply suggest that we keep the original gdb_begin procedure,
> but with an extra comment inside saying that we expect that this
> function might eventually be upgraded to support certain more tricky
> cases such as remote-debugging on VxWorks targets for instance (and with
> an extra optional parameter to address the issue you raised above).
> In the meantime, this function allows us to track all calls to the
> "begin" command.
>
> Sounds fair?
I would like to discuss the meaning of begin separately. You haven't
told me what the parameter is; what GDB uses it for; or why providing
something other than the name of the entry point would be useful.
Since if it isn't useful, GDB should take care of this itself on
vxworks for a uniform command syntax.
> I am happy with "adaflags", but as you have guessed, I'm a bit
> relunctant with "adacompiler". I like "gnatmake" better than
> "gnatmakecompiler" (yeeewww!). Maybe "adamake"?
Let's stick to gnatmake. If someday (unlikely, but hey...) DejaGNU is
used to test some other Ada compiler, I bet it won't have a foomake
that takes gnatmake arguments.
> It sounded like a good idea, and I added the following check.
>
> if ![info proc find_gnatmake] {
> # If the version of dejagnu being used does not provide
> # procedure find_gnatmake, then we know the build will fail.
> # Better to bail out gracefully now rather than having
> # dejagnu abort the entire run later when it finds it needs
> # this procedure but can't find it.
> verbose "find_gnatmake procedure not found. Update dejagnu?"
> return "Ada compilation failed: find_gnatmake procedure not found."
> }
>
> However, since find_gnatmake will only be called iff target_compile
> (which is in dejagnu:target.exp) is upgraded to recognize the "ada"
> option keyword. Otherwise, I've tried it, it defaults to using gcc.
> And the gdb_compile_ada then fails without aborting the entire
> testsuite run. So it looks like we can do without the extra check.
But it will fail messily after trying to use GCC to compile Ada source,
right? That's what I want to avoid.
> [1] At least on VxWorks, the user needs to provide the name of the
> entry-point into the "executable" (aka "module") he wants to run.
> This allow GDB to tell the target where to start the execution of
> the inferior from. The extra argument is also necessary for the
> "run" command too.
Ooh, an explanatory footnote. I missed that. I understand why this
might be, but is it ever useful to the user to provide something other
than the normal, debug-info-specified entry point?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer