This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>
>
> Something is changed (and IMHO worse) with shared
> library breakpoints in post-May releases on linux.
>
>
> For years I've been doing:
> break on main
> run
> stop at main
> select breakpoints after shared libaries
> at mapped in
> cont, run
>
> (is there a better way...I recall this behavior on suns, now on linux,
> libc is mapped in before running (so it seems))
>
> : leisner@thingy; ldd $(type -p ld)
> libbfd.so.2.8.1.0.15 => /usr/gnu/binutils-2.8.1.0.15/lib/libbfd.so.2.8.1.0.15 (0x4000a000)
> libc.so.5 => /usr/local/lib/libc.so.5 (0x4009c000)
>
> I expect this behavior:
> : leisner@thingy; gdb ld
> GNU gdb 970507
> (gdb) break main
> Breakpoint 1 at 0x8058a67: file ../../ld/ldmain.c, line 163.
> (gdb) r
> Starting program: /usr/gnu/binutils/bin/ld
>
> Breakpoint 1, main (argc=1, argv=0xbffff094) at ../../ld/ldmain.c:163
> 163 long start_time = get_run_time ();
> (gdb) break bfd_elf32_bfd_final_link
> Breakpoint 2 at 0x4004e660: file ../../bfd/elfcode.h, line 234.
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /usr/gnu/binutils/bin/ld
> Cannot insert breakpoint 2:
> Temporarily disabling shared library breakpoints:
> 2
>
> Breakpoint 1, main (argc=1, argv=0xbffff094) at ../../ld/ldmain.c:163
> 163 long start_time = get_run_time ();
> (gdb) quit
>
>
> Which is what I expect...
>
> Now I'm getting this:
>
> : leisner@thingy; gdb-980122 ld
> GNU gdb 980122
> This GDB was configured as "i586-pc-linux-gnulibc1"...
> (gdb) break main
> Breakpoint 1 at 0x8058a67: file ../../ld/ldmain.c, line 163.
> (gdb) r
> Starting program: /usr/gnu/binutils/bin/ld
>
> Breakpoint 1, main (argc=1, argv=0xbffff094) at ../../ld/ldmain.c:163
> 163 long start_time = get_run_time ();
> (gdb) break bfd_elf32_bfd_final_link
> Breakpoint 2 at 0x4004e660: file ../../bfd/elfcode.h, line 234.
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /usr/gnu/binutils/bin/ld
> Cannot insert breakpoint 2:
> Cannot access memory at address 0x4004e660.
>
> I looked at breakpoint.c and didn't see what would account for this behavior
> (except if its at a high level).
>
> Note on sunos 4.1.4, I'm not getting this behavior (with a elf32 cross-linker):
I got the same behavior on Solaris 2.5.1:
# gnu/bin/gdb/solaris/gdb/gdb a.out
GNU gdb 980122
Copyright 1997 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.5.1"...
(gdb) b main
Breakpoint 1 at 0x10898: file e.cc, line 5.
(gdb) r
Starting program: /home/hlu/tmp/a.out
Breakpoint 1, main () at e.cc:5
5 cout << "Hellow world" << endl;
(gdb) step
ostream::operator<< (this=0x20b30, s=0x10978 "Hellow world")
at /home/hlu/gnu/import/egcs/libio/iostream.cc:756
756 if (opfx())
(gdb) b
Breakpoint 2 at 0xef7727e0: file
/home/hlu/gnu/import/egcs/libio/iostream.cc, line 756.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/hlu/tmp/a.out
Cannot insert breakpoint 2:
Cannot access memory at address 0xef7727e0.
(gdb) c
Continuing.
Cannot insert breakpoint 2:
Cannot access memory at address 0xef7727e0.
H.J.