Re: Recent Linux related changes to gdb...

Re: Recent Linux related changes to gdb...

[Mark Kettenis]

   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;

Re: Recent Linux related changes to gdb...

[Kevin Buettner]

On Sep 12,  5:19pm, Jim Blandy wrote:

> > 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.

I have reverted the linux-specific changes for printing out registers
and the state of the FPU.

We would very much like to restore this lost functionality by unifying
FP support for the various i386 implementations.  I know that a number
of you were active in discussions regarding FP support unification
earlier this summer.  If you have patches, send them our way!  :)

Those of you watching the number of test suite failures on Linux will
notice that there is now one more failure than before (info float).

Kevin
From ac131313ATcygnus.com Mon Sep 13 19:00:00 1999
From: Andrew Cagney <ac131313 AT cygnus.com>
To: gdb AT sourceware.cygnus.com
Subject: ser*.[hc] cleanups
Date: Mon, 13 Sep 1999 19:00:00 -0000
Message-id: <37DDAA8D.E318C6C4@cygnus.com>
X-SW-Source: 1999-q3/msg00345.html
Content-length: 464

FYI,

I've just checked in the first of a number of cleanups to the serial
code.  This round only contained cosmetic changes:

	o	stripped out K&R style declarations

	o	replaced macro's directly calling functions
		with indirect function calls.

Next is to consolidate ser-tcp, ser-unix and ser-pipe so that they are
ready for some async changes that Elena is preparing.

	enjoy,
		Andrew

PS: It got through basic testing, testing continuing....
From hjlATlucon.org Mon Sep 13 20:05:00 1999
From: hjl AT lucon.org (H.J. Lu)
To: kevinb AT cygnus.com (Kevin Buettner)
Cc: jimb AT cygnus.com (Jim Blandy), kettenis AT wins.uva.nl (Mark Kettenis), gdb AT sourceware.cygnus.com
Subject: Re: Recent Linux related changes to gdb...
Date: Mon, 13 Sep 1999 20:05:00 -0000
Message-id: <19990914030544.CAB091B493@ocean.lucon.org>
References: <990914005505.ZM10413@ocotillo.lan>
X-SW-Source: 1999-q3/msg00346.html
Content-length: 1242

> 
> I have reverted the linux-specific changes for printing out registers
> and the state of the FPU.
> 
> We would very much like to restore this lost functionality by unifying
> FP support for the various i386 implementations.  I know that a number
> of you were active in discussions regarding FP support unification
> earlier this summer.  If you have patches, send them our way!  :)
> 
> Those of you watching the number of test suite failures on Linux will
> notice that there is now one more failure than before (info float).
> 

I believe that other none-Linux OSes are protected in my original
x86 fpu patch for gdb 4.17. I don't remember it was very hard to do.
I have access to Solaris 7/x86. I can do it again.

# gdb
GNU gdb 4.17.0.14 with Linux support
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 "i386-pc-solaris2.7".
(gdb) info float
No floating point info available for this processor.
(gdb) 


-- 
H.J. Lu (hjl@gnu.org)
From ac131313ATcygnus.com Mon Sep 13 20:07:00 1999
From: Andrew Cagney <ac131313 AT cygnus.com>
To: Andrew Cagney <ac131313 AT cygnus.com>, gdb AT sourceware.cygnus.com
Subject: Re: ser*.[hc] cleanups
Date: Mon, 13 Sep 1999 20:07:00 -0000
Message-id: <37DDBBB9.4F831AAE@cygnus.com>
References: <37DDAA8D.E318C6C4@cygnus.com>
X-SW-Source: 1999-q3/msg00347.html
Content-length: 1230

Andrew Cagney wrote:
> 
> FYI,
> 
> I've just checked in the first of a number of cleanups to the serial
> code.  This round only contained cosmetic changes:
> 
>         o       stripped out K&R style declarations
> 
>         o       replaced macro's directly calling functions
>                 with indirect function calls.
> 
> Next is to consolidate ser-tcp, ser-unix and ser-pipe so that they are
> ready for some async changes that Elena is preparing.

I got asked what what I ment by consoliadate.  It's actually very
simple.

ser-{tcp,unix,pipe}.c are, to varying degrees, clones of each other. 
They are all based on the unix/FD model and the assumption that
non-blocking and timed reads on scb->fd are possible.  They even contain
the same bugs!  By consolidate I mean:

	o	identifying common operations between these
		three and merging them.

		The common functionality could either live in
		(new) ser-fd.[hc] or the existing ser-unix.[hc].
		I've not thought that far ahead.

		A must have.

	o	Investigate the possibility of revising serial.h
		so that access to ``struct _serial_t'' is restricted.
		This is to stop generic GDB code poking around in
		that objects internals.

		A nice to have.

enjoy,

	Andrew
From elizATgnu.org Tue Sep 14 02:26:00 1999
From: Eli Zaretskii <eliz AT gnu.org>
To: hjl AT lucon.org (H.J. Lu)
Cc: gdb AT sourceware.cygnus.com
Subject: Re: Your change to can_use_hardware_watchpoint breaks hw wp
Date: Tue, 14 Sep 1999 02:26:00 -0000
Message-id: <199909140925.FAA15491@mescaline.gnu.org>
References: <19990913173629.3FA211B493@ocean.lucon.org> <199909131721.NAA03983@mescaline.gnu.org>
X-SW-Source: 1999-q3/msg00348.html
Content-length: 978

> > 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.

Even changes specific to Linux are useful, as one can look at them and
devise similar changes for other x86-based targets.

> BTW, I can set hardware watchpoints on array element, struct member
> and 4 long long, float, double or long double.

Are the changes to do this in the current CVS tree?  If so, could you
please point me to the relevant source files and functions where these
changes are implemented?

If you didn't submit your changes, may I suggest to do so?  I think that
the (practical) inability to watch array elements and struct members
is a grave problem.
From hjlATlucon.org Tue Sep 14 08:01:00 1999
From: hjl AT lucon.org (H.J. Lu)
To: gdb AT sourceware.cygnus.com (GDB)
Subject: Please update jv-exp.tab.c in CVS.
Date: Tue, 14 Sep 1999 08:01:00 -0000
Message-id: <19990914150120.F2B6F1B493@ocean.lucon.org>
X-SW-Source: 1999-q3/msg00349.html
Content-length: 178

Hi,

I have reported that jv-exp.tab.c is older than jv-exp.y in CVS.
Could someone please either remove jv-exp.tab.c from CVS or
update it?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
From hjlATlucon.org Tue Sep 14 10:35:00 1999
From: hjl AT lucon.org (H.J. Lu)
To: kevinb AT cygnus.com (Kevin Buettner)
Cc: jimb AT cygnus.com (Jim Blandy), kettenis AT wins.uva.nl (Mark Kettenis), gdb AT sourceware.cygnus.com
Subject: Re: Recent Linux related changes to gdb...
Date: Tue, 14 Sep 1999 10:35:00 -0000
Message-id: <19990914173436.3C7F21B493@ocean.lucon.org>
References: <990914005505.ZM10413@ocotillo.lan>
X-SW-Source: 1999-q3/msg00350.html
Content-length: 972

> I have reverted the linux-specific changes for printing out registers
> and the state of the FPU.
> 
> We would very much like to restore this lost functionality by unifying
> FP support for the various i386 implementations.  I know that a number
> of you were active in discussions regarding FP support unification
> earlier this summer.  If you have patches, send them our way!  :)
> 
> Those of you watching the number of test suite failures on Linux will
> notice that there is now one more failure than before (info float).
> 

If you take a look at my patch for gdb 4.17.0.13, you will find out

1. The x86 FPU support is written for both Linux and none-Linux OSes.
2. It supports Linuxthreads on x86, alpha and ppc. It is not hard to
add for other archs. Since I only had access to x86, alpha and ppc
at the time, they were the only ones enabled.

The gdb in cvs doesn't have any of those. I will see what I can do.
It is kind of mess.

-- 
H.J. Lu (hjl@gnu.org)
From hjlATvaresearch.com Tue Sep 14 12:04:00 1999
From: hjl AT varesearch.com (H.J. Lu)
To: gdb AT sourceware.cygnus.com (GDB)
Subject: A patch for x86 FPU
Date: Tue, 14 Sep 1999 12:04:00 -0000
Message-id: <19990914190359.43F953FC1@varesearch.com>
X-SW-Source: 1999-q3/msg00351.html
Content-length: 7828

With this kludge, I built gdb on both Linux/x86 and Solaris 7/x86.


-- 
H.J. Lu (hjl@gnu.org)
--
Tue Sep 14 11:48:49 1999  H.J. Lu  <hjl@gnu.org>

	* config/i386/tm-i386.h (FPC_REGNUM): Defined as -1
	(FPCONTROL_REGNUM, FPSTATUS_REGNUM, FPTAG_REGNUM, FPIPO_REGNUM,
	FPIPS_REGNUM, FPOOS_REGNUM, FPOPS_REGNUM): New.
	
	* config/i386/tm-linux.h (FPSTART_REGNUM): Undefine it before
	defining.
	(FPCONTROL_REGNUM): Likewise.
	(FPSTATUS_REGNUM): Likewise.
	(FPTAG_REGNUM): Likewise.
	(FPDATA_REGNUM): Likewise.
	(FPEND_REGNUM): Likewise.

	* i386-tdep.c (i386_extract_return_value): Protect
	LOW_RETURN_REGNUM.
	(i386_print_register): Protect FPSTART_REGNUM.

	* i387-tdep.c (i387_print_register): Check FPREG_RAW_SIZE only
	if it is defined. Protect FPDATA_REGNUM and FPSTART_REGNUM.

	* config/i386/xm-i386sol2.h: New.

	* config/i386/i386sol2.mh (XM_FILE): Set to xm-i386sol2.h.

Index: config/i386/tm-i386.h
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/i386/tm-i386.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 tm-i386.h
--- config/i386/tm-i386.h	1999/09/09 00:38:38	1.1.1.1
+++ config/i386/tm-i386.h	1999/09/14 17:37:28
@@ -108,7 +108,15 @@ extern int i386_skip_prologue PARAMS ((i
 #define PS_REGNUM 9		/* (ps)  Contains processor status */
 
 #define FP0_REGNUM 16		/* (st0) 387 register */
-#define FPC_REGNUM 25		/* 80387 control register */
+#define FPC_REGNUM -1		/* 80387 control register */
+
+#define FPCONTROL_REGNUM FPC_REGNUM
+#define FPSTATUS_REGNUM -1	/* FPU status register */
+#define FPTAG_REGNUM -1		/* FPU tag register */
+#define FPIPO_REGNUM -1		/* FPU instruction pointer offset register */
+#define FPIPS_REGNUM -1		/* FPU instruction pointer selector egister */
+#define FPOOS_REGNUM -1		/* FPU operand pointer offset register */
+#define FPOPS_REGNUM -1		/* FPU operand pointer selector register */
 
 /* Total amount of space needed to store our copies of the machine's register
    state, the array `registers'. */
Index: config/i386/i386sol2.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/i386/i386sol2.mh,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386sol2.mh
--- config/i386/i386sol2.mh	1999/09/09 00:38:38	1.1.1.1
+++ config/i386/i386sol2.mh	1999/09/14 18:28:46
@@ -1,6 +1,6 @@
 # Host: Intel 386 running Solaris 2 (SVR4)
 
-XM_FILE= xm-i386v4.h
+XM_FILE= xm-i386sol2.h
 XDEPFILES= 
 
 NAT_FILE= nm-i386sol2.h
Index: i386-tdep.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/i386-tdep.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 i386-tdep.c
--- i386-tdep.c	1999/09/09 00:38:38	1.1.1.1
+++ i386-tdep.c	1999/09/14 16:56:54
@@ -691,6 +691,7 @@ i386_extract_return_value (type, regbuf,
   else
 #endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET*/
     {
+#ifdef LOW_RETURN_REGNUM
       int len = TYPE_LENGTH (type);
       int low_size = REGISTER_RAW_SIZE (LOW_RETURN_REGNUM);
       int high_size = REGISTER_RAW_SIZE (HIGH_RETURN_REGNUM);
@@ -708,6 +709,9 @@ i386_extract_return_value (type, regbuf,
 	}
       else
 	error ("GDB bug: i386-tdep.c (i386_extract_return_value): Don't know how to find a return value %d bytes long", len);
+#else /* LOW_RETURN_REGNUM */
+      memcpy (valbuf, regbuf, TYPE_LENGTH (type));
+#endif /* LOW_RETURN_REGNUM */
     }
 }
 
@@ -961,6 +965,8 @@ set_disassembly_flavor ()
     set_architecture_from_arch_mach (bfd_arch_i386, bfd_mach_i386_i386_intel_syntax);
 }
 
+#ifdef FPSTART_REGNUM
+
 /* Print the register regnum, or all registers if regnum is -1 */
 
 void
@@ -1005,6 +1011,8 @@ i386_print_register (raw_regs, regnum, f
     for (i = FPSTART_REGNUM; i < FPEND_REGNUM; i++)
       i387_print_register (raw_regs, i);
 }
+
+#endif /* FPSTART_REGNUM */
 
 void
 _initialize_i386_tdep ()
Index: i387-tdep.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/i387-tdep.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 i387-tdep.c
--- i387-tdep.c	1999/09/14 14:51:26	1.1.1.2
+++ i387-tdep.c	1999/09/14 18:53:36
@@ -160,21 +160,48 @@ i387_print_register (raw_regs, regnum)
   unsigned swd, tags, expon, top, norm, ls, ms;
   char string[12];
 
-#if (FPREG_RAW_SIZE != 10)
+#if defined(FPREG_RAW_SIZE) && (FPREG_RAW_SIZE != 10)
 #error "Bad FPREG_RAW_SIZE"
 #endif
 
   printf_filtered ("%8.8s: ", REGISTER_NAME (regnum));
+#ifdef FPDATA_REGNUM
   if (regnum < FPDATA_REGNUM)
+#else
+  if (REGISTER_RAW_SIZE (regnum) == 4)
+#endif
     {
       val = extract_unsigned_integer (raw_regs + REGISTER_BYTE (regnum), 4);
+#ifdef FPSTART_REGNUM
       if ( (regnum < FPSTART_REGNUM + 3) ||
 	   (regnum == FPSTART_REGNUM + 6) )
 	/* Don't print the un-modifiable bytes. */
 	sprintf(string, "0x%04x", val & 0xffff);
       else
 	sprintf(string, "0x%08x", val);
+#else
+      switch (regnum)
+	{
+	case FPCONTROL_REGNUM:
+#if FPSTATUS_REGNUM != -1
+	case FPSTATUS_REGNUM:
+#endif
+#if FPTAG_REGNUM != -1
+	case FPTAG_REGNUM:
+#endif
+#if FPOPS_REGNUM != -1
+	case FPOPS_REGNUM:
+#endif
+	  /* Don't print the un-modifiable bytes. */
+	  sprintf(string, "0x%04x", val & 0xffff);
+	  break;
 
+	default:
+	  sprintf(string, "0x%08x", val);
+	  break;
+	}
+#endif
+
       printf_unfiltered ("%10.10s", string);
 
       if (regnum == FPCONTROL_REGNUM)
@@ -185,8 +212,12 @@ i387_print_register (raw_regs, regnum)
   else
     {
       /* An FPU stack register. */
+#ifdef FPREG_RAW_SIZE
       if ( REGISTER_RAW_SIZE (regnum) != FPREG_RAW_SIZE )
 	error ("GDB bug: i387-tdep.c (i387_print_register): wrong size for FPU stack register");
+#else
+#define FPREG_RAW_SIZE REGISTER_RAW_SIZE (regnum)
+#endif
 
       /* Put the data in the buffer.  No conversions are ever necessary. */
       memcpy (virtual_buffer, raw_regs + REGISTER_BYTE (regnum),
@@ -206,6 +237,9 @@ i387_print_register (raw_regs, regnum)
       
       puts_unfiltered ("  ");
       special = 0;
+#ifndef FPDATA_REGNUM
+#define	FPDATA_REGNUM FP0_REGNUM
+#endif
       switch ((tags >> (((regnum - FPDATA_REGNUM + top) & 7) * 2)) & 3) 
 	{
 	case 0: puts_unfiltered ("Valid "); break;
@@ -278,6 +312,7 @@ i387_print_register (raw_regs, regnum)
 
 void i387_float_info(void)
 {
+#ifdef FPSTART_REGNUM
   char raw_regs [REGISTER_BYTES];
   int i;
 
@@ -286,6 +321,7 @@ void i387_float_info(void)
 
   for (i = FPSTART_REGNUM; i <= FPEND_REGNUM; i++)
     i387_print_register (raw_regs, i);
+#endif
 }
 
 #ifdef LD_I387
--- /dev/null	Tue May  5 13:32:27 1998
+++ config/i386/xm-i386sol2.h	Tue Sep 14 11:29:56 1999
@@ -0,0 +1,6 @@
+#include "i386/xm-i386v4.h"
+
+/* On sol2.7, <curses.h> emits a bunch of 'macro redefined'
+   warnings, which makes autoconf think curses.h doesn't 
+   exist.  Compensate fot that here. */
+#define HAVE_CURSES_H 1
Index: config/i386/tm-linux.h
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/i386/tm-linux.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 tm-linux.h
--- config/i386/tm-linux.h	1999/09/09 00:38:38	1.1.1.1
+++ config/i386/tm-linux.h	1999/09/14 18:58:49
@@ -74,11 +75,17 @@
 #define LOW_RETURN_REGNUM 0	/* holds low four bytes of result */
 #define HIGH_RETURN_REGNUM 2	/* holds high four bytes of result */
 
+#undef FPSTART_REGNUM
 #define FPSTART_REGNUM	  16    /* start of FPU registers */
+#undef FPCONTROL_REGNUM
 #define FPCONTROL_REGNUM  16	/* FPU control register */
+#undef FPSTATUS_REGNUM
 #define FPSTATUS_REGNUM   17	/* FPU status register */
+#undef FPTAG_REGNUM
 #define FPTAG_REGNUM	  18    /* FPU tag register */
+#undef FPDATA_REGNUM
 #define FPDATA_REGNUM     23	/* actual floating-point values */
+#undef FPEND_REGNUM
 #define FPEND_REGNUM	  (FPSTART_REGNUM + 14)	/* last FPU register */
 
 #define FPENV_BYTES (7 * 4)
From crashATdollarCOMPANYNAME.com Tue Sep 14 16:10:00 1999
From: Jason Molenda <crash AT dollarCOMPANYNAME.com>
To: Stan Shebs <shebs AT cygnus.com>
Cc: gdb AT sourceware.cygnus.com
Subject: Re: Test suite for GDB?
Date: Tue, 14 Sep 1999 16:10:00 -0000
Message-id: <19990914161028.A18371@cygnus.com>
References: <199909142218.SAA22748@delysid.gnu.org> <199909142243.PAA04574@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00352.html
Content-length: 665

 [ on bug-gdb someone asks if GDB has a testsuite ]

On Tue, Sep 14, 1999 at 03:43:19PM -0700, Stan Shebs wrote:

> Yes indeed, there is such a thing - it's not shipped with the standard
> GDB distribution, mostly for historical reasons I suspect.  

I included the testsuite in the main tarfile when I released 4.17 and
didn't hear any howling.  I think we need to stop distributing the
testsuite separately.  It only adds about 7% to the overall tar file,
not a big deal.

I suspect JimB included a separate -testsuite.tar.gz files for 4.18 only
because that's what the release documentation called for.

Does anyone really care either way?

J
Free the Software!
From mh15ATst-andrews.ac.uk Wed Sep 15 00:56:00 1999
From: Mark Hindley <mh15 AT st-andrews.ac.uk>
To: gdb AT sourceware.cygnus.com
Subject: Debugging Windows Namespace extension dll
Date: Wed, 15 Sep 1999 00:56:00 -0000
Message-id: <l03130300b404ff236a3b@[138.251.135.28]>
X-SW-Source: 1999-q3/msg00353.html
Content-length: 876

I am in the middle of writing a windows namespace extension implemented as
an in process server dll. I have got the basic structure complete and it
builds fine with gcc, but I can not get it to debug with gdb.

I am trying:

exec-file /windows/explorer.exe

source-file MyDll.dll

set args /root, {My CLSID},


There appears to be 2 problems. I get an access violation when the dll is
read, eith as the initial symbol file, or when it is loaded by explorer
when the programme is run. The other is that I am unable to set any
breakpoints. If I type

break DllMain

the reply is

Cannot access memory at 0x....

However if I run, everything is fine up to the GPF which I am trying to debug!

Any suggestions? If I can't get it to debug through gdb, I will have to
resort to one of Mr Gate's overpriced products which will be very painful!

Thanks for your help


Mark Hindley