This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Testsuite FAIL which isn't a FAIL in chng-syms.exp
Hi Daniel,
On Feb 26 11:32, Daniel Jacobowitz wrote:
> Take a look at gdb_run_cmd:
> gdb_expect 60 {
> -re "The program .* has been started already.*y or n. $" {
> send_gdb "y\n"
> exp_continue
> }
> -re "Starting program: \[^\r\n\]*" {}
> }
>
> It eats everything up to "Starting program" so the error has been
> hidden. I'm not sure quite why this passes for me... aha, yes I am:
>
> `/opt/src/binutils/x86-as/gdb/testsuite/gdb.base/chng-syms' has changed; re-reading symbols.
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
> Starting program:
> /opt/src/binutils/x86-as/gdb/testsuite/gdb.base/chng-syms
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
>
> The other copies of the message come at the shared library breakpoint
> when we try to reset shlib_disabled breakpoints. You're probably
> running an embedded target that doesn't have a shared library event
> breakpoint.
Yes, that's right and...
> Not sure what the best fix is. Might work as a hack to add -notransfer
> to gdb_run_cmd:
>
> -notransfer -re "Starting program: \[^\r\n\]*" {}
...this actually fixes it.
> That will leave the "Starting program" in the buffer, and anything else
> transfered for that match. I'm not sure if this will break any other
> tests.
True, that looks a bit dangerous :-)
> As an aside, in the original test:
>
> > -re "Error in re-setting .*No symbol .var1..*Program exited normally.*" {
>
> is not a safe pattern; never suffix a pattern with .*. The end should
> always be anchored, usually to "$gdb_prompt $".
Yes, I tried that as one of the first measurements against the FAIL but
it's clear now why that had no effect.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.