[Bug shlibs/11497] New: Stepping broken

[Bug shlibs/11497] New: Stepping broken

[andre dot poenitz at nokia dot com]

I cannot do a simple 'step' into a function on an arm-linux-gnueabi based device
(Nokia N900) with any recent version of gdb.

Anything coming after 

Author: Joel Brobecker <brobecker@gnat.com>
Date:   Mon Sep 17 19:32:53 2007 +0000

            * solib-svr4.c: Add include of "auxv.h".
            (enable_break): Use the AT_BASE auxiliary entry if available.
            * Makefile.in (solib-svr4.o): Update dependencies.

appears to be broken.

Current CVS head can be made "working" by applying the following patch:
-------------------------------------------------------------------
diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 8edc889..1524722 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1449,7 +1449,7 @@ enable_break (struct svr4_info *info, int from_tty)

       /* If we were not able to find the base address of the loader
          from our so_list, then try using the AT_BASE auxilliary entry.  */
-      if (!load_addr_found)
+      if (0 && !load_addr_found)
         if (target_auxv_search (&current_target, AT_BASE, &load_addr) > 0)
          {
            int addr_bit = gdbarch_addr_bit (target_gdbarch);
-------------------------------------------------------------------

(but this makes startup much slower)

The final problem is that the breakpoint inserted for the stepping is set on an
address that's never hit, possibly due to a relocation problem. The packet
delivered looks like

>&"Packet received: 80340141\n"
>&"Sending packet: $X13c14,4:\\360\\001\\360\\347#e6..."

whereas the "working" version uses different addresses like

>&"Sending packet: $Xa5b8,4:,0K\\342#ab..." 
>&"Packet received: OK\n"
>&"Sending packet: $Xaeb8,4:40\\e\\345#b6..." 
>&"Packet received: OK\n" 
>&"Sending packet: $X4100e77c,4:\\004\\260-\\345#b3..." 
>&"Packet received: OK\n" 
>&"Sending packet: $X41052330,4:\\000@\\240\\341#45..."

Maybe this is some kind of relocation problem?

-- 
           Summary: Stepping broken
           Product: gdb
           Version: 7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: shlibs
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: andre dot poenitz at nokia dot com
                CC: gdb-prs at sourceware dot org
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-linux-gnueabi


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-13 16:52 -------

In case it matters, on the device there is a 

  GNU gdbserver (GDB) 6.8.50.20090417-debian

I don't know whether this was possibly patched.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[jan dot kratochvil at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan dot kratochvil at redhat
                   |                            |dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[jan dot kratochvil at redhat dot com]

------- Additional Comments From jan dot kratochvil at redhat dot com  2010-04-13 17:57 -------
Created an attachment (id=4725)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4725&action=view)
interp_text debug patch

Would work this patch instead?
[rfc] Fix "step" for ld.so debugging
http://sourceware.org/ml/gdb-patches/2010-01/msg00397.html

Also:
from the start: set verbose on
I some `set debug target 1' or `info break' etc. instead of "X" packets.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 08:50 -------
Applying the patch from 

  http://sourceware.org/bugzilla/attachment.cgi?id=4725&action=view

creates the following output:

"~"r 1 pc 0xaa50 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa54 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa58 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa5c interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa60 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa64 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa68 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa6c interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa70 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa74 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacc0 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacc4 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacc8 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaccc interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacd0 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacd4 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacd8 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacdc interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xace0 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xace4 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xace8 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacec interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xacf0 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa78 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa7c interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa80 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa84 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa88 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xa070 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xa074 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xa078 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0x9f00 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0x9f04 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0x9f08 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0x9f0c interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 0 pc 0x41013480 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0]
in_plt 0\n"


Applying additionally the patch from

   http://sourceware.org/ml/gdb-patches/2010-01/msg00397.html

fixes the problem indeed (and does not have the performance impact as my initial
workaround had). There was no extra output in this case, so presumably the
svr4_in_dynsym_resolve_code() is not called at all anymore after applying the
second patch.

Thanks a lot for this really quick help!

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-04-14 10:57 -------
You weren't originally stopped in ld.so or in a plt when you did "step", right?

How does that patch fix your problem then?

There's still a reachable call to in_solib_dynsym_resolve_code after the patch
that you should be seeing, isn't it?  How do you not see any extra output?

...
       && in_solib_dynsym_resolve_code (stop_pc) <<<<<<<< here
+      && !(ecs->event_thread->step_range_start > 1
+	 && in_solib_dynsym_resolve_code (ecs->event_thread->step_range_start))


How is this:

       && 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))

catching your case then?  Are you reaching this bit at the end of
handle_inferior_event when you do "step" ?

  /* We aren't done stepping.

     Optimize by setting the stepping range to the line.
     (We might not be in the original line, but if we entered a
     new line in mid-statement, we continue stepping.  This makes
     things like for(;;) statements work better.)  */

  ecs->event_thread->step_range_start = stop_pc_sal.pc;
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ecs->event_thread->step_range_end = stop_pc_sal.end;
  set_step_info (frame, stop_pc_sal);

  if (debug_infrun)
     fprintf_unfiltered (gdb_stdlog, "infrun: keep going\n");
  keep_going (ecs);

so that after a step, it looks like to gdb that you had indeed
started a step from within ld.so or a stub (???)

It would be also helpful to see "set debug infrun 1" before/after patch.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-04-14 12:43 -------
Your logs showed "pc 0xaa50 interp-text <0x8a0..0x17950"

[0x8a0..0x17950) looks too low a range for ld.so.  It appears to indicate
gdb confused the interpreter text range with your main executable's.
Try "info sharedlibrary" just before that "step" to see the real ld.so's
text range.

That's most likely the reason the patch happens to "fix" the issue
for you.  GDB always thinks it's stepping within ld.so, while in fact
you're just stepping through the main code of your app.  This seems like
the root problem that needs fixing to me.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 12:49 -------
Created an attachment (id=4727)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4727&action=view)
infrun log before/after


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 12:50 -------
(In reply to comment #4)
> You weren't originally stopped in ld.so or in a plt when you did "step", right?

I am indeed not in ld.so, but in a  'main()' function of a tiny boiler-plate Qt
Gui application and the 'step' in question is supposed to go into the
constructor of the main window.

> How does that patch fix your problem then?

I don't know that. The problem disappears with the patch, by now this has been
verified by a colleague, too, so it's not just my imagination ;-)

> There's still a reachable call to in_solib_dynsym_resolve_code after the patch
> that you should be seeing, isn't it?  How do you not see any extra output?

I was grepping for the wrong pattern in the output. There's:

~"r 1 pc 0xaa50 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xa5b8 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xaa64 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"
>~"r 1 pc 0xa5b8 interp-text <0x8a0..0x17950] interp-plt <0x850..0x8a0] in_plt 0\n"

> ...
>        && in_solib_dynsym_resolve_code (stop_pc) <<<<<<<< here
> +      && !(ecs->event_thread->step_range_start > 1
> +	 && in_solib_dynsym_resolve_code (ecs->event_thread->step_range_start))
> 
> 
> How is this:
> 
>        && 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))
> 
> catching your case then? 

See above, my fault. Sorry.

> Are you reaching this bit at the end of
> handle_inferior_event when you do "step" ?
> 
>   /* We aren't done stepping.
> 
>      Optimize by setting the stepping range to the line.
>      (We might not be in the original line, but if we entered a
>      new line in mid-statement, we continue stepping.  This makes
>      things like for(;;) statements work better.)  */
> 
>   ecs->event_thread->step_range_start = stop_pc_sal.pc;
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ecs->event_thread->step_range_end = stop_pc_sal.end;
>   set_step_info (frame, stop_pc_sal);
> 
>   if (debug_infrun)
>      fprintf_unfiltered (gdb_stdlog, "infrun: keep going\n");
>   keep_going (ecs);
>
> so that after a step, it looks like to gdb that you had indeed
> started a step from within ld.so or a stub (???)

[This code is not hit.]
 
> It would be also helpful to see "set debug infrun 1" before/after patch.

I'll attach this.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 12:59 -------

The 'info shared' output:

(gdb) info shared
>From        To          Syms Read   Shared Object Library
0x000008a0  0x00017950  Yes (*)     /arm-sysroot/lib/ld-linux.so.3
0x40137618  0x409305b0  No          /arm-sysroot/usr/lib/libQtGui.so.4
0x4445bd40  0x446480d8  No          /arm-sysroot/usr/lib/libQtCore.so.4
0x00003cc0  0x00012c18  No          /arm-sysroot/lib/libpthread.so.0
0x416b0b18  0x4172cf58  No          /arm-sysroot/usr/lib/libstdc++.so.6
0x413231b0  0x413564f8  No          /arm-sysroot/lib/libm.so.6
0x4117a190  0x41181670  No          /arm-sysroot/lib/libgcc_s.so.1
0x4103c6f0  0x41121b84  No          /arm-sysroot/lib/libc.so.6
0x41460f44  0x41462860  No          /arm-sysroot/usr/lib/libgthread-2.0.so.0
0x411915d0  0x41194f30  No          /arm-sysroot/lib/librt.so.1
0x411b7718  0x412383e0  No          /arm-sysroot/usr/lib/libglib-2.0.so.0
0x41803810  0x4181cc24  No          /arm-sysroot/usr/lib/libpng12.so.0
0x413d16ec  0x413db8b8  No          /arm-sysroot/usr/lib/libz.so.1
0x4175f664  0x417aea20  No          /arm-sysroot/usr/lib/libfreetype.so.6
0x412de7cc  0x4130ef80  No          /arm-sysroot/usr/lib/libgobject-2.0.so.0
0x466a0fb0  0x466a12ac  No          /arm-sysroot/usr/lib/libEGL.so
0x45031714  0x45035e60  No          /arm-sysroot/usr/lib/libSM.so.6
0x44f33900  0x44f41920  No          /arm-sysroot/usr/lib/libICE.so.6
0x41991410  0x419976d4  No          /arm-sysroot/usr/lib/libXrender.so.1
0x417d3f20  0x417ebca8  No          /arm-sysroot/usr/lib/libfontconfig.so.1
0x418328c0  0x4183dd68  No          /arm-sysroot/usr/lib/libXext.so.6
0x41513a68  0x4159d63c  No          /arm-sysroot/usr/lib/libX11.so.6
0x412c892c  0x412c96d0  No          /arm-sysroot/lib/libdl.so.2
0x464d1770  0x464da698  No          /arm-sysroot/usr/lib/libIMGegl.so
0x414ba208  0x414d2944  No          /arm-sysroot/usr/lib/libexpat.so.1
0x414e0954  0x414e14c8  No          /arm-sysroot/usr/lib/libXau.so.6
0x414f0f10  0x414f2774  No          /arm-sysroot/usr/lib/libXdmcp.so.6
0x44fd1dcc  0x44fe1400  No          /arm-sysroot/usr/lib/libsrv_um.so
0x40aca3cc  0x40accb20  No          /arm-sysroot/usr/lib/gconv/UTF-16.so
0x41477d08  0x414887d8  No          /arm-sysroot/usr/lib/libgconf-2.so.4
0x413c0c74  0x413c1d04  No          /arm-sysroot/usr/lib/libgmodule-2.0.so.0
0x4139e24c  0x413aee94  No          /arm-sysroot/usr/lib/libdbus-glib-1.so.2
0x4128d118  0x412b61f4  No          /arm-sysroot/usr/lib/libdbus-1.so.3
0x41ba1250  0x41ba5ff8  No          /arm-sysroot/usr/lib/libXrandr.so.2
0x41af0f60  0x41af379c  No          /arm-sysroot/usr/lib/libXfixes.so.3
0x41ac1e70  0x41ac6d24  No          /arm-sysroot/usr/lib/libXcursor.so.1
0x41a395d4  0x41a407d0  No          /arm-sysroot/usr/lib/libXi.so.6
0x41c22be8  0x41e7ffd4  No          /arm-sysroot/usr/lib/libgtk-x11-2.0.so.0
0x415fb2f8  0x4160bb88  No          /arm-sysroot/usr/lib/libgdk_pixbuf-2.0.so.0
0x41b22c28  0x41b7228c  No          /arm-sysroot/usr/lib/libgdk-x11-2.0.so.0
0x41adb258  0x41adfaa8  No          /arm-sysroot/usr/lib/libpangocairo-1.0.so.0
0x41b00f14  0x41b03edc  No          /arm-sysroot/usr/lib/libXtst.so.6
0x41bb892c  0x41bb9614  No          /arm-sysroot/usr/lib/libXcomposite.so.1
0x41bc8850  0x41bc9354  No          /arm-sysroot/usr/lib/libXdamage.so.1
0x41f5e6b0  0x41f6b5b4  No          /arm-sysroot/usr/lib/libatk-1.0.so.0
---Type <return> to continue, or q <return> to quit---
0x41a573c8  0x41aa42bc  No          /arm-sysroot/usr/lib/libcairo.so.2
0x413fe360  0x4144b87c  No          /arm-sysroot/usr/lib/libgio-2.0.so.0
0x41a0cd40  0x41a2a54c  No          /arm-sysroot/usr/lib/libpangoft2-1.0.so.0
0x4162a1e8  0x4164b2c0  No          /arm-sysroot/usr/lib/libpango-1.0.so.0
0x419ab960  0x419fa938  No          /arm-sysroot/usr/lib/libpixman-1.so.0
0x4206fab0  0x420a78ec  No          /arm-sysroot/usr/lib/libgnomevfs-2.so.0
0x4187ab70  0x4195c280  No          /arm-sysroot/usr/lib/libxml2.so.2
0x41f99f24  0x41fa4690  No          /arm-sysroot/lib/libresolv.so.2
0x418509b4  0x418510f4  No          /arm-sysroot/lib/libutil.so.1
0x41ffdae8  0x4204b644  No          /arm-sysroot/usr/lib/libhildon-1.so.0
0x41fd1d5c  0x41fdbef0  No          /arm-sysroot/usr/lib/libcanberra.so.0
0x41fb99f0  0x41fbe1d8  No          /arm-sysroot/usr/lib/libltdl.so.7
0x42aa8aa8  0x42ad7fc0  No          /arm-sysroot/usr/lib/libhildonfm.so.2
0x426eabd0  0x426f0ff8  No          /arm-sysroot/usr/lib/libhildonthumbnail.so.0
0x427aa2cc  0x427ae3a0  No          /arm-sysroot/usr/lib/libhildonmime.so.0
0x424c24c4  0x424c8208  No          /arm-sysroot/usr/lib/libtrackerclient.so.0
0x40b03850  0x40b0a0fc  No          /arm-sysroot/lib/libnss_files.so.2
0x40b16978  0x40b1d11c  No         
/arm-sysroot/usr/lib/gtk-2.0/2.10.0/engines/libsapwood.so
0x40b2870c  0x40b2d6b8  No         
/arm-sysroot/usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
0x40adbf98  0x40ae20d0  No         
/arm-sysroot/usr/lib/gtk-2.0/2.10.0/immodules/hildon-im-module.so
0x43590794  0x43590ab8  No          /arm-sysroot/usr/lib/libhildon_im_common.so.3
0x40aeba14  0x40aebe9c  No         
/arm-sysroot/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
0x4245c7fc  0x42463144  No          /arm-sysroot/usr/lib/libgvfscommon.so.0
0x40b79bc4  0x40b89be4  No          /arm-sysroot/usr/lib/gio/modules/libgvfsdbus.so
0x40af62bc  0x40af7c64  No         
/arm-sysroot/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so
(*): Shared library is missing debugging information.
(gdb) 


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 13:37 -------
Maps on the device after gdbserver startup:

/tmp $ cat /proc/5544/maps 

00008000-0000c000 r-xp 00000000 b3:02 16397      /home/developer/n900test
00013000-00014000 rw-p 00003000 b3:02 16397      /home/developer/n900test
41000000-4101c000 r-xp 00000000 fe:01 1997       /lib/ld-2.5.so
41023000-41025000 rw-p 0001b000 fe:01 1997       /lib/ld-2.5.so
bebbb000-bebd0000 rw-p befeb000 00:00 0          [stack]

Maps as seen by gdb after 'attach':


(gdb) target remote 192.168.2.15:10000
Remote debugging using 192.168.2.15:10000
infrun: clear_proceed_status_thread (Thread 5544)
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun:   42000 [Thread 5544],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x410008a0
infrun: quietly stopped
infrun: stop_stepping
Reading symbols from /arm-sysroot/lib/ld-linux.so.3...(no debugging symbols
found)...done.
Loaded symbols for /arm-sysroot/lib/ld-linux.so.3
0x410008a0 in ?? ()
(gdb)
(gdb) info shared
>From        To          Syms Read   Shared Object Library
0x000008a0  0x00017950  Yes (*) /arm-sysroot/lib/ld-linux.so.3
(*): Shared library is missing debugging information.
(gdb)


ld-linux.so.3 is identical to some file ld-2.5.so in the sysroot.

There are differences between the sysroot files and the actual files on the device.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 13:43 -------

Copying over /lib/* to the sysroot leads to:

>From        To          Syms Read   Shared Object Library
0x410008a0  0x41017950  Yes (*)     /arm-sysroot/lib/ld-linux.so.3


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug shlibs/11497] Stepping broken

[andre dot poenitz at nokia dot com]

------- Additional Comments From andre dot poenitz at nokia dot com  2010-04-14 13:55 -------
Using the same binaries in the sysroot as on the device makes the problem go away.
*blush*

[The remaining interesting fact is that startup times is now slower again, maybe
that indicates that now some/more useful data is transfered.]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=11497

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.