Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Dec 03, 2004 at 10:15:05AM -0800, Randolph Chung wrote:
> > Anyway, more relevant, and as daniel asked, can it be done in assember? 
> >  A starting point for that might be the gdb.asm test case which uses 
> > assembly source code.
> 
> i'm working on it, but getting stuck with a weird problem... i'm seeing
> a case where i do:
> 
> proc get_addr_of_sym { sym } {
>   set addr 0
>   global gdb_prompt
>   global expect_out

Not sure but I don't think you need to declare expect_out as a global.

>   send_gdb "print $sym\n"
>   gdb_expect 60 {
>     -re ".*($hex) <$sym>.*$gdb_prompt $" {
>       set addr $expect_out(1,string)
>       pass "got address of $sym = $addr"
>     }
>     timeout {
>       fail "cannot get address of $sym (timed out)."
>       gdb_suppress_tests
>     }
>   }
> 
>   return $addr
> }
> 
> set foo [get_addr_of_sym "foo"]
> set bar [get_addr_of_sym "bar"]
> 
> i always get a FAIL on that, and from looking at the log (with --debug)
> it seems like the gdb_expect is returning immediately without checking
> for results from the previous send_gdb command....
> 
> viz:
> send: sending "print foo\n" to { exp11 }^M
> FAIL: gdb.arch/pa-nullify.exp: cannot get address of foo (timed out).
> send: sending "print bar\n" to { exp11 }^M
> FAIL: gdb.arch/pa-nullify.exp: cannot get address of bar (timed out).
> 
> am i doing something obviously wrong?

First, as Andrew mentioned, don't use gdb_expect this way.  Use
gdb_test_multiple.

Secondly, there are two possible causes of this.  One is a syntax
error, in either the regular expression or the code for the matching
case. That will invoke the "timeout" handler. The other is that you've
gotten out of sync somehow; doesn't look too likely from the above.

Try putting "exp_internal 1" in front of it to see what expect thinks
it is doing.

I just saw the bug: try "global hex" and see if that helps.

-- 
Daniel Jacobowitz