This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix variable objects for references to pointers
- From: Daniel Jacobowitz <drow at false dot org>
- To: Nick Roberts <nickrob at snap dot net dot nz>
- Cc: Vladimir Prus <ghost at cs dot msu dot su>, gdb-patches at sources dot redhat dot com
- Date: Wed, 3 Jan 2007 17:55:32 -0500
- Subject: Re: [PATCH] Fix variable objects for references to pointers
- References: <17792.55489.274138.854508@kahikatea.snap.net.nz> <E1Gujg6-0003rU-38@zigzag.lvk.cs.msu.su> <17793.7666.771432.41360@kahikatea.snap.net.nz>
On Thu, Dec 14, 2006 at 10:48:34PM +1300, Nick Roberts wrote:
> + mi_runto reference_to_pointer
> +
> + set end_of_proc [gdb_get_line_number "return 99;"]
> + send_gdb "-exec-next 4\n"
> + gdb_expect {
> + -re "\\^running\r\n${mi_gdb_prompt}\\*stopped,reason=\"end-stepping-range\",thread-id=\"\[01\]\",frame=\{addr=\"$hex\",func=\"reference_to_pointer\",args=\\\[\\\],file=\".*${srcfile}\",fullname=\"${fullname_syntax}${srcfile}\",line=\"$end_of_proc\"\}\r\n$mi_gdb_prompt$" {
> + pass "4xnext to return 99"
> + }
> + timeout { fail "4xnext in reference_to_pointer (timeout)" }
> + }
Using send_gdb / gdb_expect this way is a problem. If anything goes
wrong, then the test will sit until it times out. There's only
one pattern, so you could use mi_gdb_test. "-exec-next 4"
isn't great either; compiler changes or test changes can easily
make you end up somewhere unexpected.
This line isn't testing anything you're interested in, right?
Then you can just put a breakpoint in the right place and run
to that breakpoint. I'd recommend mi_continue_to. I don't
see a convenient helper in mi-support.exp to set the breakpoint, but
there's an example in mi-var-cmd.exp.
(Hardcoding the breakpoint number that way isn't great either
but I'll clean that up another day.)
--
Daniel Jacobowitz
CodeSourcery