Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux)

[Michael Snyder <msnyder@cygnus.com>]

Andrew Cagney wrote:

> LONGEST is C's equivalent to ``long'' the longest type and can fit a
> CORE_ADDR.

Hmmm, no, LONGEST has nothing to do with a CORE_ADDR.
LONGEST is the largest integer type available in the compiler.
If the compiler supports (long long), then LONGEST is (long long).
Else it's usually long.  It's a convention for "gimme the biggest
int ya got".
From ac131313@cygnus.com Tue Jun 20 21:42:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: msnyder@cygnus.com
Cc: James Wilson <wilson@cygnus.com>, Jim Blandy <jimb@cygnus.com>, ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: gdb patch for 64-bit enum values on 64-bit hosts (ia64-linux)
Date: Tue, 20 Jun 2000 21:42:00 -0000
Message-id: <395047AE.BA21BB8F@cygnus.com>
References: <200006200213.TAA22932@wilson.cygnus.com> <395013E2.D78A2EE2@cygnus.com> <395037E9.73C3@cygnus.com>
X-SW-Source: 2000-06/msg00259.html
Content-length: 714

Michael Snyder wrote:
> 
> Andrew Cagney wrote:
> 
> > LONGEST is C's equivalent to ``long'' the longest type and can fit a
> > CORE_ADDR.

> Hmmm, no, LONGEST has nothing to do with a CORE_ADDR.
> LONGEST is the largest integer type available in the compiler.

well:

	sizeof (CORE_ADDR) >= TARGET_PTR_BIT / HOST_CHAR_BIT

	sizeof (LONGEST) >= TARGET_LONG_LONG_BIT / HOST_CHAR_BIT

	CORE_ADDR is a host integer type large enough to hold
		a canonical target address

	LONGEST is the largest host integer type supported by the host

giving:

	sizeof (LONGEST) >= sizeof (CORE_ADDR) :-)

Much code (unfortunatly?) assumes that a CORE_ADDR can be passed into a
LONGEST (whether doing so is correct or not).

	Andrew
From eliz@delorie.com Wed Jun 21 00:05:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kevinb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] TARGET_ADJUST_BREAKPOINT_ADDRESS...
Date: Wed, 21 Jun 2000 00:05:00 -0000
Message-id: <200006210705.DAA02630@indy.delorie.com>
References: <1000621031433.ZM31859@ocotillo.lan>
X-SW-Source: 2000-06/msg00260.html
Content-length: 959

> Date: Tue, 20 Jun 2000 20:14:33 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> 
> If a breakpoint address is adjusted, there's some new code in
> breakpoint.c which'll print out a warning.  Such a warning might
> look something like this...
> 
> 	(gdb) b foo
> 	warning: Breakpoint address moved from 0x06200090 to 0x0620008c.
> 	Breakpoint 1 at 0x0620008c: file bar.c, line 21.

Printing a message is a good idea, but making it a warning IMHO is
not.  Warning is for some potential trouble, while in this case GDB is
doing The Right Thing.  Printing a warning will confuse users.

Perhaps we should make the information about moving the breakpoint
part of the "Breakpoint 1 at ..." message.

My other comment is about hardware-assisted breakpoints: it looks
like, at least in some of the examples you gave, the address of
hardware-assisted breakpoints will also need to be adjusted in the
same way.  So I think we need some provision for that as well.
From muller@cerbere.u-strasbg.fr Wed Jun 21 03:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, taylor@cygnus.com, ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Pascal language part 4: Changes to symfile.c: commited
Date: Wed, 21 Jun 2000 03:00:00 -0000
Message-id: <200006211020.MAA25998@cerbere.u-strasbg.fr>
References: <Pierre> <Muller's> <message> <of> <Mon,> <19> <Jun> <2000> <12:57:27> <+0200> <200006191048.MAA24798@cerbere.u-strasbg.fr> <200006191123.NAA25313@cerbere.u-strasbg.fr>
X-SW-Source: 2000-06/msg00261.html
Content-length: 1510

>This table is used for deriving the language from the compilation
>unit's main source file.  Unless people compile .inc files separately,
>.inc shouldn't appear here.

  OK, I thought it was based on the current file extension,
I then of course completely agree that .inc should not be included.

>If you remove .inc from the list, and then discover you have problems,
>please let us know.
>
>This change is approved, assuming Mark's and my suggestions are
>followed.

  Thus I commited the following:

ChangeLog entry:

2000-06-21  Pierre Muller  <muller@ics.u-strasbg.fr>
   * symfile.c (init_filename_language_table): add ".pas", ".p" and ".pp"
   as pascal source file extensions.

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.14
diff -c -r1.14 symfile.c
*** symfile.c	2000/06/16 21:02:21	1.14
--- symfile.c	2000/06/21 09:56:46
***************
*** 1925,1930 ****
--- 1925,1933 ----
        add_filename_language (".F", language_fortran);
        add_filename_language (".s", language_asm);
        add_filename_language (".S", language_asm);
+       add_filename_language (".pas", language_pascal);
+       add_filename_language (".p", language_pascal);
+       add_filename_language (".pp", language_pascal);
      }
  }
  
 


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From muller@cerbere.u-strasbg.fr Wed Jun 21 03:37:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb-patches@sourceware.cygnus.com
Subject: Pascal language support patch4: commit error
Date: Wed, 21 Jun 2000 03:37:00 -0000
Message-id: <200006211057.MAA26574@cerbere.u-strasbg.fr>
References: <Pierre> <Muller's> <message> <of> <Mon,> <19> <Jun> <2000> <12:57:27> <+0200> <200006191048.MAA24798@cerbere.u-strasbg.fr> <200006191123.NAA25313@cerbere.u-strasbg.fr>
X-SW-Source: 2000-06/msg00262.html
Content-length: 605

  I made a small erro when committing my patch for symfile.c which resulted
in 
a wrong formating of the ChangeLog entry and some text that was not
appropriate
at that place (revision 1.495)

  As I noticed it just after my commit, I took the liberty to recommit
ChangeLog (v 1.496)
directly after with the correct info. I hope this was not an abuse of the
commit rules
by myself.

  With the deepest apologies for this error. 


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From macro@ds2.pg.gda.pl Wed Jun 21 07:12:00 2000
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: gdb-patches@sourceware.cygnus.com
Subject: gdb 5.0: Distclean in sim/common does not remove cconfig.h (fwd)
Date: Wed, 21 Jun 2000 07:12:00 -0000
Message-id: <Pine.GSO.3.96.1000621161304.28897O-100000@delta.ds2.pg.gda.pl>
X-SW-Source: 2000-06/msg00263.html
Content-length: 1208

---------- Forwarded message ----------
Message-ID: <Pine.GSO.3.96.1000619183456.10348N-100000@delta.ds2.pg.gda.pl>
Date: Mon, 19 Jun 2000 18:40:36 +0200 (MET DST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: bug-gdb@gnu.org
Subject: gdb 5.0: Distclean in sim/common does not remove cconfig.h

Hi,

 Upon running `make distclean' sim/common/cconfig.h does not get removed. 
That's probably because the generated file used to be named config.h.  The
following obvious patch fixes the problem for me. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

diff -u --recursive --new-file gdb-5.0.macro/sim/common/Makefile.in gdb-5.0/sim/common/Makefile.in
--- gdb-5.0.macro/sim/common/Makefile.in	Mon Jul 19 23:29:41 1999
+++ gdb-5.0/sim/common/Makefile.in	Sat Jun 17 13:12:53 2000
@@ -113,7 +113,7 @@
 distclean mostlyclean maintainer-clean realclean: clean
 	rm -f TAGS
 	rm -f Makefile config.cache config.log config.status
-	rm -f config.h stamp-h
+	rm -f cconfig.h stamp-h
 
 # Dummy target to force execution of dependent targets.
 force: