This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada


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


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