Re: Recent Linux related changes to gdb...

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Sat, 11 Sep 1999 06:46:11 -0700
   From: Kevin Buettner <kevinb@cygnus.com>

   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 <jimb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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: <npogf7bwne.fsf@zwingli.cygnus.com>
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  <jimb@savonarola.red-bean.com>

	Change from Ian Lance Taylor <ian@zembu.com>.  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 <eliz@gnu.org>
To: "H.J. Lu" <hjl@varesearch.com>
Cc: GDB <gdb@sourceware.cygnus.com>
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> <npyafct7d4.fsf@zwingli.cygnus.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 <eliz@gnu.org>
To: "H.J. Lu" <hjl@varesearch.com>
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 <eliz@gnu.org>
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 <kevinb AT cygnus.com>
To: Ian Lance Taylor <ian AT zembu.com>, 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> <ian@zembu.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;