From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6913 invoked by alias); 5 Mar 2004 16:48:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6899 invoked from network); 5 Mar 2004 16:48:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Mar 2004 16:48:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AzIUh-0006GY-Jq; Fri, 05 Mar 2004 11:48:15 -0500 Date: Fri, 05 Mar 2004 16:48:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada Message-ID: <20040305164815.GB23778@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040305060322.GD1226@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00107.txt 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6913 invoked by alias); 5 Mar 2004 16:48:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6899 invoked from network); 5 Mar 2004 16:48:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Mar 2004 16:48:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AzIUh-0006GY-Jq; Fri, 05 Mar 2004 11:48:15 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada Message-ID: <20040305164815.GB23778@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040305060322.GD1226@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00107.txt.bz2 Message-ID: <20040319000900.5LBEwX3ASVDmAVCtvymcWuHMVjosXxUoqi7rtsAeFbg@z> 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