This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Add tests for JIT debugging interface
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