[RFC] problem in solib-svr4/enable_break

[RFC] problem in solib-svr4/enable_break

[Michael Snyder]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

The attached patch isn't for submission, but just to help
illustrate the problem.  It fixes a symptom but seems kludgy
to me (and not well understood).

Here's the problem.  I have a kernel image which is statically
linked and PIE.  When it gets to enable_break, it succeeds in
finding "debug_base", but "debug_base" is in the text section
of the main executable (ie. not in the dynamic loader, which is
not actually present).

Therefore we compute info->interp_text_sect_low and
info->interp_text_sect_high as the start and end of the text
section of the main executable.  And therefore whenever we
call in_solib_dynsym_resolve_code(), it returns TRUE, and
therefore source level stepping won't work.


This simple patch just checks to see whether "tmp_bfd" (which
is supposed to be the dynamic loader) matches exec_bfd, and
if so, lets interp_text_sect_low and interp_text_sect_high
remain zero.

Anybody got a better suggestion?


[-- Attachment #2: svr4.txt --]
[-- Type: text/plain, Size: 706 bytes --]

Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.110
diff -u -p -r1.110 solib-svr4.c
--- solib-svr4.c	8 Jan 2010 22:52:03 -0000	1.110
+++ solib-svr4.c	14 Jan 2010 21:57:37 -0000
@@ -1312,7 +1312,10 @@ enable_break (struct svr4_info *info, in
 				os->objfile->sect_index_text);
 
 	  interp_sect = bfd_get_section_by_name (tmp_bfd, ".text");
-	  if (interp_sect)
+
+	  /* Skip if tmp_bfd points to main executable.  */
+	  if (interp_sect
+	      && strcmp (tmp_bfd->filename, exec_bfd->filename) != 0)
 	    {
 	      info->interp_text_sect_low =
 		bfd_section_vma (tmp_bfd, interp_sect) + load_addr;

[rfc] Fix "step" for ld.so debugging [Re: [RFC] problem in solib-svr4/enable_break]

[Jan Kratochvil]

Hi Michael,

I see there is a problem for debugging ld.so even on native GNU/Linux when
I get some intentional way into the ld.so code.  Existing problem:
(gdb) frame
#0  _dl_fixup (l=0x7ffff7ffe0e8, reloc_arg=<value optimized out>) at ../elf/dl-runtime.c:90
90	  if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0)
(gdb) next
94	      if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL)
(gdb) next
99		  version = &l->l_versions[ndx];
(gdb) next
100		  if (version->hash == 0)
(gdb) step
pause () at ../sysdeps/unix/syscall-template.S:82
82	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)

("next" works but "step" skips whole ld.so resolver)

Wouldn't the patch below also solve your "PIE kernel" problem?

No regressions on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu.
But I am not much sure about some possible regressions with this code.


Regards,
Jan


2010-01-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* infrun.c (handle_inferior_event): Continue stepping through dynsym
	resolve code only if STEP_RANGE_START was not in dynsym resolve code.

--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -4115,8 +4115,9 @@ infrun: not switching back to stepped thread, it has vanished\n");
   /* If we are stepping at the source level and entered the runtime
      loader dynamic symbol resolution code...
 
-     EXEC_FORWARD: we keep on single stepping until we exit the run
-     time loader code and reach the callee's address.
+     EXEC_FORWARD: we keep on single stepping until we exit the run time loader
+     code and reach the callee's address.  Permit normal stepping inside loader
+     code if user already started the stepping there.
 
      EXEC_REVERSE: we've already executed the callee (backward), and
      the runtime loader code is handled just like any other
@@ -4126,7 +4127,9 @@ infrun: not switching back to stepped thread, it has vanished\n");
 
   if (execution_direction != EXEC_REVERSE
       && ecs->event_thread->step_over_calls == STEP_OVER_UNDEBUGGABLE
-      && in_solib_dynsym_resolve_code (stop_pc))
+      && in_solib_dynsym_resolve_code (stop_pc)
+      && !(ecs->event_thread->step_range_start > 1
+	 && in_solib_dynsym_resolve_code (ecs->event_thread->step_range_start)))
     {
       CORE_ADDR pc_after_resolver =
 	gdbarch_skip_solib_resolver (gdbarch, stop_pc);

Re: [rfc] Fix "step" for ld.so debugging [Re: [RFC] problem in solib-svr4/enable_break]

[Michael Snyder]

Jan Kratochvil wrote:
> Hi Michael,
> 
> I see there is a problem for debugging ld.so even on native GNU/Linux when
> I get some intentional way into the ld.so code.  Existing problem:
> (gdb) frame
> #0  _dl_fixup (l=0x7ffff7ffe0e8, reloc_arg=<value optimized out>) at ../elf/dl-runtime.c:90
> 90	  if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0)
> (gdb) next
> 94	      if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL)
> (gdb) next
> 99		  version = &l->l_versions[ndx];
> (gdb) next
> 100		  if (version->hash == 0)
> (gdb) step
> pause () at ../sysdeps/unix/syscall-template.S:82
> 82	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> 
> ("next" works but "step" skips whole ld.so resolver)
> 
> Wouldn't the patch below also solve your "PIE kernel" problem?
> 
> No regressions on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu.
> But I am not much sure about some possible regressions with this code.

Jan, thanks, I can see the logic, and it does indeed fix my
symptom.  Are you thinking of checking it in?