Bug in GDB 5.0
Program: GDB 5.0 Build: arm-elf, running on a Redhat Linux 6.x host to perform remote debugging Problem: xbreak Description: When using the xbreak command, I find that it does not put the breakpoint in the proper location. It seems to put the breakpoint at the first opcode AFTER the end of the function in question, rather than at the last opcode of the function in question (which is typically a "ldmdb" opcode). This problem seems to occur regardless of whether or not the program is compiled with "-O0" or "-O2". Thank you. --Gary Parnes [EMAIL PROTECTED] ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
[Bug-gdb] gdb-5.0: cross build for VAX on Solaris fails (patch included)
gcc-2.95.2 chokes when trying to dereference (struct frameinfo *fi) at vax-tdep.c line 70. Fix: --- gdb/,vax-tdep.c Wed Jul 7 22:11:10 1999 +++ gdb/vax-tdep.c Mon Sep 18 16:16:27 2000 @@ -21,6 +21,7 @@ #include "defs.h" #include "symtab.h" #include "opcode/vax.h" +#include "frame.h" /* Vax instructions are never longer than this. */ #define MAXLEN 62 Regards, V.B. ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
[Bug-gdb] Re: Suspected bug in GDB 5.0 -- SIGSEV sent for unaligned access instead of SIGBUS
Older versions of GDB had this in procfs.c:
#endif /* not FAULTED_USE_SIGINFO */
default:
/* Use the signal which the kernel assigns. This is better than
trying to second-guess it from the fault. In fact, I suspect
that FLTACCESS can be either SIGSEGV or SIGBUS. */
#ifdef UNIXWARE
statval = ((pi-prstatus.pr_lwp.pr_info.si_signo) 8) | 0177;
#else
statval = ((pi-prstatus.pr_info.si_signo) 8) | 0177;
#endif
break;
which has been left out during a procfs.c overhaul and causes the behaviour
you are observing.
The new code has some FIXMEs though:
switch (what) { /* FIXME: FAULTED_USE_SIGINFO */
/* FIXME: use si_signo where possible. */
default: /* FIXME: use si_signo if possible for fault */
so it seems that the problem is known.
I do not know enough about other procfs implementations (UNIXWARE, IRIX etc.)
to come up with a proper fix, sorry.
Dear gdb maintainer,
Versions of gdb prior to 5.0 delivered a SIGBUS
for an unaligned access. The shell has this behavior,
too. However, gdb 5.0 interprets unaligned accesses
as SIGSEGV. This is a problem when debugging programs
that use SIGBUS.
Here is an example of a program with an unaligned
access running in gdb 4.17 and gdb 5.0:
/mnt3/jlp gcc -g signal.c
/mnt3/jlp a.out
Bus Error
/mnt3/jlp cat signal.c
int main()
{
union {
char c[4];
long *lP;
} u;
*u.lP = malloc(5);
u.c[3]++;
*u.lP = 42;
return 0;
}
/mnt3/jlp
/mnt3/jlp /usr/local/bin/gdb-4.17 a.out
GNU gdb 4.17
Copyright 1998 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.6"...
(gdb) b main
Breakpoint 1 at 0x10564: file signal.c, line 10.
(gdb) r
Starting program: /mnt3/jlp/a.out
in gdb. .cshrc was not sourced
Breakpoint 1, main () at signal.c:10
10 *u.lP = malloc(4);
(gdb) n
11 u.c[3]++;
(gdb)
13 *u.lP = 42;
(gdb)
Program terminated with signal SIGBUS, Bus error.
The program no longer exists.
(gdb) quit
/mnt3/jlp gdb a.out
GNU gdb 5.0 (UI_OUT)
Copyright 2000 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.7"...
(gdb) b main
Breakpoint 1 at 0x10564: file signal.c, line 10.
(gdb) r
Starting program: /mnt3/jlp/a.out
in gdb. .cshrc was not sourced
Breakpoint 1, main () at signal.c:10
10 *u.lP = malloc(4);
(gdb) n
11 u.c[3]++;
(gdb)
13 *u.lP = 42;
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x00010590 in main () at signal.c:13
13 *u.lP = 42;
(gdb) quit
The program is running. Exit anyway? (y or n) y
/mnt3/jlp
--
Peter Schauer [EMAIL PROTECTED]
___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb
bug in gdb-5.0 (and other versions)
I have reported and traced down problem with setting (resetting) breakpoints in shared libraries earlier. The problem exists in 4.18 but also in 5.0. The problem occurs when you do a debug session and rerun the session. All dynamically loaded libraries will be unloaded upon rerun, set breakpoints will be remembered and reused for the new run. When the program is rerun, gdb tries to set the breakpoints again but finds that it cannot resolve the addresses on which these stored breakpoints should be reset (because the addresses are not loaded yet). This generates a lot of error messages since gdb tries to set these addresses several times. Later when the library gets loaded and gdb again tries to set the breakpoint, it correctly resolves the addresses. However, the returned address is identical to the address that is stored in the remembered breakpoint data structure (this is normal since dynamic libraries get loaded on the same address upon each sucessive run). Because of this IDENTICAL address, gdb WRONGLY concludes that the breakpoint is still set (armed) and should therefore NOT be rearmed. I think that the cached addresses should be cleaned out (set to 0x000) for dynamic libraries that get unloaded when rerun). I tracked down this problem to the code that tests whether to set or not a breakpoint. THIS IS THE 5 TIME I REPORT THIS ERROR AND ITS ANALYSIS. IT IS A SEVERE PROBLEM AND I AM SURE THAT THE ABOVE EXPLANATION COVERS THE PROBLEM. I HAVE TRACKED THIS DOWN FOR 2 DAYS TRYING TO FIX IT MYSELF BUT ALTHOUGH I KNOW WHY THE ERROR OCCURS AND ALSO WHAT CODE IS IN ERROR I DO NOT KNOW THE CLEAN/NICE/ELEGANT WAY TO FIX IT. IS THERE ANYBODY WHO CAN LOOK INTO THIS ! Wim Delvaux
