Regression loading a tracefile in 7_3

Regression loading a tracefile in 7_3

[Marc Khouzam]

Hi,

I believe I'm seeing a regression loading a tracefile in GDB 7.3
I create a simple tracefile using GDB/gdbserver 7.3 but when I try to load
that tracefile, I get an error about "PC register is not available", which
causes my Eclipse session to abort.  This is not happening in 7.2 or 7.2.1.

> gdb.7.3 a.out
GNU gdb (GDB) 7.2.90.20110519-cvs
(gdb) interpreter-exec mi "-target-select tfile trace.7.3"
~"Created tracepoint 1 for target's tracepoint 1 at 0x804851f.\n"
^error,msg="PC register is not available"

Things might be ok after that, meaning that tstatus seems ok, and
tfind works ok.  But the ^error reply is a problem.

It's caused by a recent added check in regcache.c:regcache_read_pc ()
for the return value of regcache_cooked_read_unsigned()

      if (regcache_cooked_read_unsigned (regcache,
					 gdbarch_pc_regnum (gdbarch),
					 &raw_val) == REG_UNAVAILABLE)
	throw_error (NOT_AVAILABLE_ERROR, _("PC register is not available"));

I don't know if I'm doing something wrong, but I wanted to report it right
away to avoid having a regression in the 7.3 release.

Any help appreciated.

Thanks

Marc

Below is how I created the trace file:

> gdb.7.3 a.out
GNU gdb (GDB) 7.2.90.20110519-cvs
(gdb) target remote :9999
Remote debugging using :9999
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
0x00258850 in ?? () from /lib/ld-linux.so.2
(gdb) l
1       #include <unistd.h>
2       #include <stdio.h>
3
4       int main() {
5           int max = 9;
6           for (int i=0;i<max;i++) {
7               printf("i is %d\n",i);
8               sleep(1);
9           }
10          return 0;
(gdb) trace 7
Tracepoint 1 at 0x804851f: file loopfirst.cc, line 7.
(gdb) command
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>collect $locals
>end
(gdb) tstart
(gdb) b 10
Breakpoint 2 at 0x8048553: file loopfirst.cc, line 10.
(gdb) c
Continuing.

Breakpoint 2, main () at loopfirst.cc:10
10          return 0;
(gdb) tstop
(gdb) tstatus
Trace stopped by a tstop command.
Collected 9 trace frames.
Trace buffer has 5239739 bytes of 5242880 bytes free (0% full).
Trace will stop if GDB disconnects.
Not looking at any trace frame.
(gdb) tsave trace.7.3
Trace data saved to file 'trace.7.3'.

Re: Regression loading a tracefile in 7_3

[Pedro Alves]

Hi Marc,

I'll take a look.

On Friday 20 May 2011 03:03:20, Marc Khouzam wrote:
> Hi,
> 
> I believe I'm seeing a regression loading a tracefile in GDB 7.3
> I create a simple tracefile using GDB/gdbserver 7.3 but when I try to load
> that tracefile, I get an error about "PC register is not available", which
> causes my Eclipse session to abort.  This is not happening in 7.2 or 7.2.1.
> 
> > gdb.7.3 a.out
> GNU gdb (GDB) 7.2.90.20110519-cvs
> (gdb) interpreter-exec mi "-target-select tfile trace.7.3"
> ~"Created tracepoint 1 for target's tracepoint 1 at 0x804851f.\n"
> ^error,msg="PC register is not available"
> 
> Things might be ok after that, meaning that tstatus seems ok, and
> tfind works ok.  But the ^error reply is a problem.
> 
> It's caused by a recent added check in regcache.c:regcache_read_pc ()
> for the return value of regcache_cooked_read_unsigned()
> 
>       if (regcache_cooked_read_unsigned (regcache,
> 					 gdbarch_pc_regnum (gdbarch),
> 					 &raw_val) == REG_UNAVAILABLE)
> 	throw_error (NOT_AVAILABLE_ERROR, _("PC register is not available"));
> 
> I don't know if I'm doing something wrong, but I wanted to report it right
> away to avoid having a regression in the 7.3 release.
> 
> Any help appreciated.
> 
> Thanks
> 
> Marc
> 
> Below is how I created the trace file:
> 
> > gdb.7.3 a.out
> GNU gdb (GDB) 7.2.90.20110519-cvs
> (gdb) target remote :9999
> Remote debugging using :9999
> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/ld-linux.so.2
> 0x00258850 in ?? () from /lib/ld-linux.so.2
> (gdb) l
> 1       #include <unistd.h>
> 2       #include <stdio.h>
> 3
> 4       int main() {
> 5           int max = 9;
> 6           for (int i=0;i<max;i++) {
> 7               printf("i is %d\n",i);
> 8               sleep(1);
> 9           }
> 10          return 0;
> (gdb) trace 7
> Tracepoint 1 at 0x804851f: file loopfirst.cc, line 7.
> (gdb) command
> Type commands for breakpoint(s) 1, one per line.
> End with a line saying just "end".
> >collect $locals
> >end
> (gdb) tstart
> (gdb) b 10
> Breakpoint 2 at 0x8048553: file loopfirst.cc, line 10.
> (gdb) c
> Continuing.
> 
> Breakpoint 2, main () at loopfirst.cc:10
> 10          return 0;
> (gdb) tstop
> (gdb) tstatus
> Trace stopped by a tstop command.
> Collected 9 trace frames.
> Trace buffer has 5239739 bytes of 5242880 bytes free (0% full).
> Trace will stop if GDB disconnects.
> Not looking at any trace frame.
> (gdb) tsave trace.7.3
> Trace data saved to file 'trace.7.3'.
> 
> 
> 
> 

-- 
Pedro Alves

Re: Regression loading a tracefile in 7_3

[Pedro Alves]

On Friday 20 May 2011 03:03:20, Marc Khouzam wrote:
> Hi,
> 
> I believe I'm seeing a regression loading a tracefile in GDB 7.3
> I create a simple tracefile using GDB/gdbserver 7.3 but when I try to load
> that tracefile, I get an error about "PC register is not available", which
> causes my Eclipse session to abort.  This is not happening in 7.2 or 7.2.1.
> 
> > gdb.7.3 a.out
> GNU gdb (GDB) 7.2.90.20110519-cvs
> (gdb) interpreter-exec mi "-target-select tfile trace.7.3"
> ~"Created tracepoint 1 for target's tracepoint 1 at 0x804851f.\n"
> ^error,msg="PC register is not available"
> 

Hmm.

#0  throw_error (error=NOT_AVAILABLE_ERROR, fmt=0x7f7908 "PC register is not available") at ../../src/gdb/exceptions.c:423
#1  0x000000000053de3a in regcache_read_pc (regcache=0xd4b280) at ../../src/gdb/regcache.c:994
#2  0x0000000000497053 in enable_break (info=0xd0df60, from_tty=1) at ../../src/gdb/solib-svr4.c:1536
#3  0x00000000004980a8 in svr4_solib_create_inferior_hook (from_tty=1) at ../../src/gdb/solib-svr4.c:2194
#4  0x000000000046faa7 in solib_create_inferior_hook (from_tty=1) at ../../src/gdb/solib.c:1240
#5  0x0000000000586de2 in post_create_inferior (target=0xbc7120, from_tty=1) at ../../src/gdb/infcmd.c:427
#6  0x00000000004d2ca8 in tfile_open (filename=0xd0d790 "/home/pedro/gdb/marck_tfile/build/gdb/./testsuite/basic.tf", from_tty=1)
    at ../../src/gdb/tracepoint.c:3410

Here, in solib-svr4.c:

      /* Otherwise we find the dynamic linker's base address by examining
	 the current pc (which should point at the entry point for the
	 dynamic linker) and subtracting the offset of the entry point.

         This is more fragile than the previous approaches, but is a good
         fallback method because it has actually been working well in
         most cases.  */
      if (!load_addr_found)
	{
	  struct regcache *regcache
	    = get_thread_arch_regcache (inferior_ptid, target_gdbarch);

	  load_addr = (regcache_read_pc (regcache)
		       - exec_entry_point (tmp_bfd, tmp_bfd_target));
	}

We could skip this if the PC is not available, but:

 - why do we even try to set a shared library breakpoint
   if the target has no execution (e.g., when debugging a core
   file) in the first place?  I'll skipping enable_break in that
   case and see if anything breaks.  By inspection, it looks like
   nothing will.  svr4_in_dynsym_resolve_code will always
   return false if we skip enable_break, but then again that function
   is only used for run control.

   (Hmm, that fallback assumes the program is stopped at the dynamic
   loader's entry point, which isn't a safe assumption when we attach
   to an inferior rather than spawning it.  Might be better to try
   anyway than not do anything at all though.)

-- 
Pedro Alves