From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: kevinb@cygnus.com Cc: kevinb@cygnus.com, jimb@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Recent Linux related changes to gdb... Date: Sat, 11 Sep 1999 13:30:00 -0000 Message-id: <199909112032.WAA00091@delius.kettenis.nl> References: <990910071005.ZM18865@ocotillo.lan> <199909110914.LAA00131@delius.kettenis.nl> <990911134610.ZM32272@ocotillo.lan> X-SW-Source: 1999-q3/msg00333.html Date: Sat, 11 Sep 1999 06:46:11 -0700 From: Kevin Buettner I must claim responsibility for breaking the other builds for the other i386 targets. Below is a patch that I'd like you (and others) to try which *should* allow the other i386 targets to build cleanly again. Thanks, the patch does indeed allow me to build gdb for i386-unknown-gnu0.2 again. I realize that merely ifdefing the code is not the ideal solution, but I think one of our goals is to unify the i386 floating point support. Think of this ifdef'd code as a placeholder for what'll eventually be there after unification has been achieved. If you are going to check in the patch, it might be a good idea to add some comments about the ifdefs being temporarily. Mark >From hjl@lucon.org Sat Sep 11 19:54:00 1999 From: hjl@lucon.org (H.J. Lu) To: gdb@sourceware.cygnus.com (GDB) Subject: Stale jv-exp.tab.c in gdb Date: Sat, 11 Sep 1999 19:54:00 -0000 Message-id: <19990912025317.9CCCC1B493@ocean.lucon.org> X-SW-Source: 1999-q3/msg00334.html Content-length: 265 Hi, >From gdb in cvs, # ls -l jv-exp.tab.c jv-exp.y -rw-r--r-- 1 hjl hjl 70246 Apr 15 18:34 jv-exp.tab.c -rw-r--r-- 1 hjl hjl 35846 Jun 21 17:13 jv-exp.y Could someone please update jv-exp.tab.c? Thanks. -- H.J. Lu (hjl@gnu.org) >From hjl@lucon.org Sat Sep 11 19:59:00 1999 From: hjl@lucon.org (H.J. Lu) To: gdb@sourceware.cygnus.com (GDB) Subject: Testsuite and watch point? Date: Sat, 11 Sep 1999 19:59:00 -0000 Message-id: <19990912025805.C615E1B493@ocean.lucon.org> X-SW-Source: 1999-q3/msg00335.html Content-length: 472 The watchpoint testcases in gdb expect only (gdb) watch a.x Watchpoint 2: a.x But with my x86 hardware watchpoint change, I can set HW watchpoint on a.x. Now I got (gdb) watch a.x Hardware watchpoint 2: a.x However, the watchpoint testcases treat it as a failure. I think the watchpoint testcases should take both "Watchpoint" and "Hardware watchpoint". I don't know much about the gdb testsuite. Otherwise, I will fix it myself. Thanks. -- oH.J. Lu (hjl@gnu.org) >From jimb@cygnus.com Sun Sep 12 15:21:00 1999 From: Jim Blandy To: Mark Kettenis Cc: kevinb@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Recent Linux related changes to gdb... Date: Sun, 12 Sep 1999 15:21:00 -0000 Message-id: References: <990910071005.ZM18865@ocotillo.lan> <199909110914.LAA00131@delius.kettenis.nl> X-SW-Source: 1999-q3/msg00336.html Content-length: 1949 > Michael Snyder has already written to tell you that Linux thread > support has been merged into gdb. If you want to try it out, fetch > the most recent gdb snapshot from sourceware.cygnus.com. > > Jim Blandy has merged various other Linux changes (in addition to the > thread related stuff) into a branch off the main Cygnus development > tree. It is my understanding that these non-thread related changes > represent the work of Bill Metzenthen, H.J. Lu, Anthony Green, and > probably others as well. (My apologies if I left your name out.) I > am pleased to report that these changes have been merged into the main > development branch and are also available via the most recent snapshot > from sourceware.cygnus.com. > > I'm not pleased at all that these changes have been merged in. They > break every non-Linux i386 target. `i386-tdep.c' has been turned into a > Linux-specific mess (for example the Linux-specific signal trampoline > handling) and symbols that are only defined in `config/i386/tm-linux.h' > are used all over the place (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM, > FPSTART_REGNUM, FPEND_REGNUM). > > I think this is unacceptable, and beg you to revert the patch until > some care has been taken that it doesn't break all the other i386 > targets, and the linux-specific signal trampoline handling has been > split-out into a seperate file. Yes, we goofed. Those changes weren't meant to go in yet. I've been gone for a month, and just got back, so communication wasn't what it should have been. As far as the trampoline code goes: 1999-07-29 Jim Blandy Change from Ian Lance Taylor . The i386_linux_sigtramp* functions should be moved to i386-linux-tdep.c, when that file is introduced. In other words: yes, that code doesn't belong there. It's not going to stay there. It shouldn't hurt you to have it there for the moment. >From eliz@gnu.org Mon Sep 13 04:25:00 1999 From: Eli Zaretskii To: "H.J. Lu" Cc: GDB Subject: Re: Your change to can_use_hardware_watchpoint breaks hw wp Date: Mon, 13 Sep 1999 04:25:00 -0000 Message-id: <199909131124.HAA23071@mescaline.gnu.org> References: <19990910000816.1B04E3FC1@varesearch.com> <199908150829.EAA01478@mescaline.gnu.org> X-SW-Source: 1999-q3/msg00337.html Content-length: 1057 > * breakpoint.c (can_use_hardware_watchpoint): Call > TARGET_REGION_OK_FOR_HW_WATCHPOINT; if it returns zero, > return zero immediately. > > I can no longer set hardware watchpoint like > > int foo [20]; > > (gdb) watch foo[1]; > > on x86. As far as I can see, this is another incarnation of a bug in GDB whereby GDB wants to watch the entire array/structure when you only need to watch one array element or one struct member. See my message to gdb-patches on 15 Aug with the Subject "Watching a struct member" and Jim Blandy's reply on 16 Aug. So the problem is not the above change, it is simply another bug that was previously hiding behind the code in can_use_hardware_watchpoint. > Do you have a patch to get it to work again? The code that evaluates expressions is very complicated, and I haven't yet figured out how to fix it. Perhaps someone who knows more about that could suggest a patch. For now, I only have a work-around: (gdb) p &foo[2] $1 = (int *) 0x9880 (gdb) watch *(int *)0x9880 Hardware watchpoint 1: *(int *) 39040 >From hjl@varesearch.com Mon Sep 13 07:15:00 1999 From: hjl@varesearch.com (H.J. Lu) To: eliz@gnu.org (Eli Zaretskii) Cc: gdb@sourceware.cygnus.com Subject: Re: Your change to can_use_hardware_watchpoint breaks hw wp Date: Mon, 13 Sep 1999 07:15:00 -0000 Message-id: <19990913141518.5DAF93FC1@varesearch.com> References: <199909131124.HAA23071@mescaline.gnu.org> X-SW-Source: 1999-q3/msg00338.html Content-length: 1665 > > > > * breakpoint.c (can_use_hardware_watchpoint): Call > > TARGET_REGION_OK_FOR_HW_WATCHPOINT; if it returns zero, > > return zero immediately. > > > > I can no longer set hardware watchpoint like > > > > int foo [20]; > > > > (gdb) watch foo[1]; > > > > on x86. > > As far as I can see, this is another incarnation of a bug in GDB > whereby GDB wants to watch the entire array/structure when you only > need to watch one array element or one struct member. See my message I knew this one. > to gdb-patches on 15 Aug with the Subject "Watching a struct member" > and Jim Blandy's reply on 16 Aug. > > So the problem is not the above change, it is simply another bug that > was previously hiding behind the code in can_use_hardware_watchpoint. I have a modified gdb. I use a kludge to watch the struct member. Could you please tell me what bug your patch tried to fix? > > > Do you have a patch to get it to work again? > > The code that evaluates expressions is very complicated, and I haven't > yet figured out how to fix it. Perhaps someone who knows more about > that could suggest a patch. > > For now, I only have a work-around: > > (gdb) p &foo[2] > $1 = (int *) 0x9880 > (gdb) watch *(int *)0x9880 > Hardware watchpoint 1: *(int *) 39040 > I don't like this work around. BTW, if you use Linux, you can try my modified gdb at ftp://ftp.valinux.com/pub/support/hjl/gdb to see if it works for you. I also have a patch for gdb snapshot which 1. Adds linuxthreads support for alpha and ppc. 2. Changes the hardware watchpoint such that I can watch array element and struct member among other things. -- H.J. Lu (hjl@gnu.org) >From eliz@gnu.org Mon Sep 13 08:12:00 1999 From: Eli Zaretskii To: "H.J. Lu" Cc: gdb@sourceware.cygnus.com Subject: Re: Your change to can_use_hardware_watchpoint breaks hw wp Date: Mon, 13 Sep 1999 08:12:00 -0000 Message-id: <199909131512.LAA22423@mescaline.gnu.org> References: <19990913141518.5DAF93FC1@varesearch.com> <199909131124.HAA23071@mescaline.gnu.org> <199908151234.IAA14013@mescaline.gnu.org> X-SW-Source: 1999-q3/msg00339.html Content-length: 1189 > Could you please tell me what bug your patch tried to fix? It fixes two problems: - the previous code used a macro that only looked at the watched region's size, whereas some platforms, like x86, need to know the address itself as well, because the alignment of the address is important in order to compute how many debug registers are required to watch the region. Hence the new macro, TARGET_REGION_OK_FOR_HW_WATCHPOINT. - the other problem, which I'm guessing is the one that caused you grief, is that the old code would simply ignore values on the value chain that were not in memory, when checking whether the expression can be watched with hardware watchpoints. By contrast, when the time came to actually insert the watchpoints, any value that is not in memory would cause GDB to fail to insert the watchpoint. The change made GDB's behavior consistent, in that it would not even try hardware watchpoints if some value on the value chain is not in memory. The latter issue was discussed on this list under the subject "Code in can_use_hardware_watchpoint()" starting on 15 Aug. The conclusion was that the change was a Good Thing. >From hjl@lucon.org Mon Sep 13 08:56:00 1999 From: hjl@lucon.org (H.J. Lu) To: eliz@gnu.org (Eli Zaretskii) Cc: gdb@sourceware.cygnus.com Subject: Re: Your change to can_use_hardware_watchpoint breaks hw wp Date: Mon, 13 Sep 1999 08:56:00 -0000 Message-id: <19990913155608.746F31B493@ocean.lucon.org> References: <199909131512.LAA22423@mescaline.gnu.org> X-SW-Source: 1999-q3/msg00340.html Content-length: 1447 > > > > Could you please tell me what bug your patch tried to fix? > > It fixes two problems: > > - the previous code used a macro that only looked at the watched > region's size, whereas some platforms, like x86, need to know the > address itself as well, because the alignment of the address is > important in order to compute how many debug registers are > required to watch the region. Hence the new macro, > TARGET_REGION_OK_FOR_HW_WATCHPOINT. > > - the other problem, which I'm guessing is the one that caused you > grief, is that the old code would simply ignore values on the value > chain that were not in memory, when checking whether the expression > can be watched with hardware watchpoints. By contrast, when the > time came to actually insert the watchpoints, any value that is not > in memory would cause GDB to fail to insert the watchpoint. The > change made GDB's behavior consistent, in that it would not even > try hardware watchpoints if some value on the value chain is not in > memory. > > The latter issue was discussed on this list under the subject "Code in > can_use_hardware_watchpoint()" starting on 15 Aug. The conclusion was > that the change was a Good Thing. > Do you have access to a Linux/x86 machine? Could you please try gdb 4.17.0.13 to see if it has the problems you tried to fix? I think my kludge works around them. Thanks. -- H.J. Lu (hjl@gnu.org) >From eliz@gnu.org Mon Sep 13 10:21:00 1999 From: Eli Zaretskii To: hjl@lucon.org (H.J. Lu) Cc: gdb@sourceware.cygnus.com Subject: Re: Your change to can_use_hardware_watchpoint breaks hw wp Date: Mon, 13 Sep 1999 10:21:00 -0000 Message-id: <199909131721.NAA03983@mescaline.gnu.org> References: <19990913155608.746F31B493@ocean.lucon.org> X-SW-Source: 1999-q3/msg00341.html Content-length: 287 > Do you have access to a Linux/x86 machine? Could you please try > gdb 4.17.0.13 to see if it has the problems you tried to fix? No, unfortunately. If you can post the changes , I will try to use them on the platform that I can use for development and see if they solve the problems. >From hjl@lucon.org Mon Sep 13 10:37:00 1999 From: hjl@lucon.org (H.J. Lu) To: eliz@gnu.org (Eli Zaretskii) Cc: gdb@sourceware.cygnus.com Subject: Re: Your change to can_use_hardware_watchpoint breaks hw wp Date: Mon, 13 Sep 1999 10:37:00 -0000 Message-id: <19990913173629.3FA211B493@ocean.lucon.org> References: <199909131721.NAA03983@mescaline.gnu.org> X-SW-Source: 1999-q3/msg00342.html Content-length: 689 > > > Do you have access to a Linux/x86 machine? Could you please try > > gdb 4.17.0.13 to see if it has the problems you tried to fix? > > No, unfortunately. If you can post the changes , I will try to use > them on the platform that I can use for development and see if they > solve the problems. > My change is specific to Linux/x86. Since gdb has been working that way on x86 for many years, I assumed I was the only person who wanted to change it. I made my change limited only to Linux/x86 so that other x86 platforms remain the same. BTW, I can set hardware watchpoints on array element, struct member and 4 long long, float, double or long double. -- H.J. Lu (hjl@gnu.org) >From kevinbATcygnus.com Mon Sep 13 12:45:00 1999 From: Kevin Buettner To: Ian Lance Taylor , kevinb AT cygnus.com, drepper AT cygnus.com, rth AT cygnus.com Cc: gdb AT sourceware.cygnus.com, binutils AT sourceware.cygnus.com, jimb AT cygnus.com Subject: Re: Zero valued N_FUN stabs in shared objects: Why? Date: Mon, 13 Sep 1999 12:45:00 -0000 Message-id: <990913194452.ZM9564@ocotillo.lan> References: <990910221813.ZM20583@ocotillo.lan> <19990910234925.15322.qmail@daffy.airs.com> X-SW-Source: 1999-q3/msg00343.html Content-length: 2135 On Sep 10, 7:49pm, Ian Lance Taylor wrote: > Why do shared objects on Solaris and Linux have zero-valued > N_FUN stabs? > > Good question. It doesn't happen with binutils 2.9.1, but it does > happen in the current development sources. > > It's because of this bit of code in elf_i386_relocate_section in > bfd/elf32-i386.c: > > /* DWARF will emit R_386_32 relocations in its > sections against symbols defined externally > in shared libraries. We can't do anything > with them here. */ > || (input_section->flags & SEC_DEBUGGING) != 0))) > > If I remove that, N_FUN stabs are no longer zero. Good call. I've tested your suggested change and it does indeed solve the problems that I was seeing on Linux. (The N_FUN stabs addresses are no longer zero, and I no longer need to enable the SOFUN_ADDRESS_MAYBE_MISSING hack in gdb to debug shared objects on linux/x86.) But Solaris/sparc is still broken... Someone (I don't know who) gave the patch below to Jim Blandy (for our customer to try), but it does not cure the problem of the N_FUN stabs being zero. Any ideas? Kevin Index: elf32-sparc.c =================================================================== RCS file: /cvs/binutils/binutils/bfd/elf32-sparc.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 elf32-sparc.c --- elf32-sparc.c 1999/05/03 07:28:56 1.1.1.1 +++ elf32-sparc.c 1999/05/17 03:54:39 @@ -1526,11 +1526,13 @@ ++sreloc->reloc_count; /* This reloc will be computed at runtime, so there's no - need to do anything now, unless this is a RELATIVE - reloc in an unallocated section. */ + need to do anything now. However, if this is a + RELATIVE or 32 reloc in an unallocated section, we + resolve it now for the benefit of gdb. */ if (skip || (input_section->flags & SEC_ALLOC) != 0 - || ELF32_R_TYPE (outrel.r_info) != R_SPARC_RELATIVE) + || (ELF32_R_TYPE (outrel.r_info) != R_SPARC_RELATIVE + && ELF32_R_TYPE (outrel.r_info) != R_SPARC_32)) continue; } break;