From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Andrew Cagney Cc: James Wilson , Jim Blandy , 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 20:39:00 -0000 Message-id: <395037E9.73C3@cygnus.com> References: <200006200213.TAA22932@wilson.cygnus.com> <395013E2.D78A2EE2@cygnus.com> X-SW-Source: 2000-06/msg00258.html 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 To: msnyder@cygnus.com Cc: James Wilson , Jim Blandy , 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 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 > > 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 To: Jim Blandy Cc: Mark Kettenis , 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: <19> <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 * 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 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: <19> <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" 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: X-SW-Source: 2000-06/msg00263.html Content-length: 1208 ---------- Forwarded message ---------- Message-ID: Date: Mon, 19 Jun 2000 18:40:36 +0200 (MET DST) From: "Maciej W. Rozycki" 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: