Re: [patch] Add tests for JIT debugging interface

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 19 January 2011 10:22:53, Paul Pluzhnikov wrote:
> On Wed, Jan 12, 2011 at 8:57 AM, Yao Qi <yao@codesourcery.com> wrote:
> > There are still two failures, which are not about 'set args' in
> > gdbserver.
> > 
> > FAIL: gdb.base/jit.exp: info function jit_function
> > FAIL: gdb.base/jit.exp: info function jit_function
> 
> Yes, I see that as well.
> 
> > info function jit_function^M
> > All functions matching regular expression "jit_function":^M
> > (gdb) FAIL: gdb.base/jit.exp: info function jit_function
> > 
> > In gdb.log, I find something strange,
> > 
> > (gdb) continue^M
> > Continuing.^M
> > jit_inferior_init, registering_code = 0^M
> > jit_inferior_init, reg_addr = 0x80486c4^M
> > jit_inferior_init, jit_descriptor_addr = 0x804a040^M
> > Cannot remove breakpoints because program is no longer writable. <-- [1]
> 
> And that.

It's output from infrun.c:normal_stop.  Sounds like a bug somewhere.

> 
> > There is no such error [1] in native gdb test.  I have no clue on this so
> > far.
> 
> That's alright -- I was going to fix this area (see "JIT interface
> slowness" in gdb@sourceware.org list), and this isn't the only problem --
> I also noticed that we leak several jit_breakpoints on rerun.
> 
> > We may re-write jit-main.c a little bit to compute the location of
> > jit-solib.so via getcwd() + argv[0], rather than passing arguments of its
> > location.
> 
> Done slightly differently.
> 
> I believe revised patch addresses all comments so far.
> 
> Thanks,

> +int main (int argc, char *argv[])
> +{
> +  /* These variables are here so they can easily be set from jit.exp  */

"main" at column 0.  Period, double space.

> +gdb_exit
> +gdb_start
> +gdb_reinitialize_dir $srcdir/$subdir
> +gdb_load $binfile

gdb_load_shlibs call missing.  This will probably need tweaking for
remote host testing, but we'll handle it when/if we stumble on it
on our testing, probably.

Did you try Yao's suggestion of using clean_restart/prepare_for_testing, etc.?
We're prefering using those whenever possible.

Other than that, this looks fine.  Please go ahead.

-- 
Pedro Alves