Re: annotate.texi

[Jim Kingdon <kingdon@redhat.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 34383 bytes --]

> I'm trying to add some indexing whenever I can.  But I suggest that
> every manual patch be scrutinized for appropriate index entries

Sounds like the voice of someone volunteering to do some scrutinization ;-).

Believe me, "people sending in lots of manual patches which never get
merged" just hasn't been a problem on any free software project I've
worked on.  Having Stan as the documentation maintainer is a good
thing too, because we are willing to hurt him if he slacks off :-).
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: akale@veritas.com (Amit S. Kale)
Cc: toddpw@windriver.com (Todd Whitesel), kingdon@redhat.com (Jim Kingdon), akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Regression caused by elfread.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002152007.MAA08037@alabama.wrs.com>
References: <00021514224700.31608@fermat.vxindia.veritas.com>
X-SW-Source: 2000-q1/msg00299.html
Content-length: 2051

> I guess gdb first prepares text, data, bss segments and following code
> bfd/section.c:bfd_make_section_anyway():
> 	newsect->index = abfd->section_count++;
> indicates that section->index contains SECT_OFF_* codes when segments are
> loaded. This may not have been designed this way, but it seems to be that way.

Yes, this looks like a desperate attempt to deal with the fundamental
numbering conflict that currently exists.

Any time stabs are read, much of GDB assumes that ANOFFSET takes SECT_OFF_*
values, even in cases where you'd expect it to take BFD section indices. So
anyone actually attempting to use BFD indices for real is plagued by subtle
bugs.

> Using sym->section->index is not right for segments that are not text or data
> segments. Using sym->section->index should be all right for data segments.

It depends on the path through the *_symfile_offsets code that is taken.

symtab.h explicitly claims that the section numbers in ANOFFSET are
"file-type-dependent" but this is largely ignored by the rest of GDB.

> I suggest following patch. I have verified that the vfprintf problem reported
> by Mark does not appear with this patch. I haven't tested it with test suite.

I guarantee you it won't completely solve the problem. But if the test suite
uses fully-linked programs, it will end up passing the tests anyway because
ANOFFSET returns 0 for all sections when a file is fully linked.

> > However, so few configurations (read: vxWorks and ??) actually use different
> > offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the
> > problems with it. (We read relocatable .o files too, which is also rare.)
> 
> It won'd be rare when gdb will be used by more people to debug linux kernel
> modules.

I hope you've got patches to symbol_file_add() and *_symfile_offsets to
accept more than one address offset for the section_offsets->offsets array.

If not, then any section loaded independently from .text is going to have
mucho problems being relocated by GDB.

-- 
Todd Whitesel
toddpw @ windriver.com
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000224133238.A723@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com>
X-SW-Source: 2000-q1/msg00402.html
Content-length: 1495

On Thu, Feb 24, 2000 at 02:12:18PM -0500, Fernando Nasser wrote:

> > When I download code with the "load" command, the byte order of
> > the data gets flipped -- it ends up in little-endian order
> > (it's big-endian in the file, and I need it to stay that way
> > when it is downloaded). Downloading with a patched 4.18 doesn't
> > have this problem.
> > 
> Grant,
> 
> What compiler, in what host and with which parameters did you
> generate your executable file?

$ uname -a
Linux grante.comtrol.com 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown

$ arm-elf-gcc --version
2.95.2

$ arm-elf-as --version
GNU assembler 991018

$ make
arm-elf-as --gstabs -EB -m arm7tdmi -amhlsnd=memconfigR10_S0_D100.lst -o memconfigR10_S0_D100.o memconfigR10_S0_D100.s
arm-elf-gcc -g -mcpu=arm7tdmi -fverbose-asm -mbig-endian -Wl,-Map,memconfigR10_S0_D100.map -nostartfiles -o memconfigR10_S0_D100 memconfigR10_S0_D100.o -T./memconfig.ld -nostdlib libgcc.a

> Is it the same one you can successifuly load with the patched 4.18?

Yes.

> In both cases you are loading the program into the AEB board, right?

No. I'm loading to custom hardware (big-endian), but I verified
that the same thing happens with the Samsung SNDS eval board
(also big-endian hardware).

I've used the EPI Jeeni (via ethernet) and the ARM Embedded ICE
(via serial port) and had the same results.

> I forgot, which host are you running gdb in?  Linux, Solaris, Cygwin?

Linux (same as above).

-- 
Grant Edwards
grante@visi.com
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: "H . J . Lu" <hjl@valinux.com>
Cc: Stan Shebs <shebs@apple.com>, gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mg0u2l3g0.fsf@jtc.redbacknetworks.com>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com>
X-SW-Source: 2000-q1/msg00575.html
Content-length: 334

>>>>> "hjl" == H J Lu <hjl@valinux.com> writes:

hjl> 2000-03-07  H.J. Lu  <hjl@gnu.org>
hjl>
hjl> 	* gdb-regex.h: New. Include <regex.h> for glibc 2 and include
hjl> 	"gnu-regex.h" otherwise.

If we follow the naming convention we have been using, gdb-regex.h
should be gdb_regex.h.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Try out the patch database
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002292134.QAA10095@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00450.html
Content-length: 858

Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
let me know what you think.

I'd like to incorporate the text of that page itself into the main GDB
page, http://sourceware.cygnus.com/gdb/ .

contribute.html refers to three new pages:

- patch-db.html, which is supposed to be everything a new contributor
  needs to know to add a patch to the patch database.

- patch-checklist.html, a checklist for submitting patches via
  E-mail.  Originally, I was going to do a template, but it seems like
  GNATS will do everything that's important automatically, so I don't
  think a template offers much benefit over simple instructions.

- assigning.html, a page explaining the copyright situation, and
  directing people to talk to me.  Eventually, of course, we'll want a
  role mail address for this, but I want to get things going quickly.
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Jim Kingdon <kingdon@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: Status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A48A0D.D7AE28C2@apple.com>
References: <38A34041.B443DAFB@apple.com> <bitzw8fvy.fsf@rtl.cygnus.com> <38A46C5C.F8301644@apple.com>
X-SW-Source: 2000-q1/msg00234.html
Content-length: 370

Stan Shebs wrote:

> There's some kind of Mach layer underneath, 2.5 I think, [...]

Ooops, should have checked http://www.apple.com/macosx/inside.html
where this is described for everybody:

	The systemÂ’s kernel [...] is based on Mach 3.0 from
	Carnegie-Mellon University and FreeBSD 3.2 (derived
	from the University of California at BerkeleyÂ’s BSD 4.4-Lite)


Stan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Gabor Z. Papp" <gzp@gzp.org.hu>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb cvs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BDE5F9.49AD7232@cygnus.com>
References: <200003011940.e21Je9528423@mail.gzp.org.hu> <20000302032052.L17285@gzp.org.hu>
X-SW-Source: 2000-q1/msg00484.html
Content-length: 324

"Gabor Z. Papp" wrote:
> 
> | cvs checkout: authorization failed: server anoncvs.cygnus.com rejected access
> 
> What is with the cvs access?

Same problem as the BINUTILS repository - it's been moved.  Both GDB and
BINUTILS are drawn from a common CVS repository.

Check http://sourceware.cygnus.com/gdb/

	enjoy,
		Andrew
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: new version of rproxy
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bya8wg9pf.fsf@rtl.cygnus.com>
References: <Pine.SGI.3.95.1000206105418.150A-100000@world.std.com>
X-SW-Source: 2000-q1/msg00131.html
Content-length: 155

> I put a new rproxy-0.6 to my web site
> http://www.std.com/qqi/labslave/rproxy.html 

Cool!  I've added a link from http://sourceware.cygnus.com/gdb/
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C220BE.44922A6@cygnus.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com> <200003050737.CAA10121@indy.delorie.com>
X-SW-Source: 2000-q1/msg00545.html
Content-length: 1020

Eli Zaretskii wrote:
> 
> > Eli Zaretskii wrote:
> > >
> > > > Well, if memory serves, if you re-ran configure in such a way that
> > > > tm.h started linking to a different file, then the config.status
> > > > dependency was the only way to force a rebuild.
> > >
> > > How about adding some #define to config.h that would also change when
> > > this happens?
> >
> > Such as the names of the tm, xm and nm files?
> 
> Yes, that's what I had in mind.  Since the configure scripts already
> knows the names of those files, it could put them into config.h.

Well I've long had in mind a ``maint build-info'' command that printed
out things like:

	tm/xm/hm.h
	the --host/target/build tupples
	the compiler
	the path to the source tree
	the build date
	the user/machine

Assuming your suggestion works (JimK doesn't find more technical flaws
(1) :-) A change putting tm/xm/hm into config.h is ok with me :-)

	Andrew

(1) I think changing tm/xm/nm happens sufficiently often for it to be
dangerous to not force a rebuild.
From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000
From: Guenther Grau <Guenther.Grau@marconicomms.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DB7FF7.E3AFDE79@marconicomms.com>
References: <200003241301.OAA04488@mail.macqel.be>
X-SW-Source: 2000-q1/msg00796.html
Content-length: 1036

Hi,

Philippe De Muyter wrote:
> Up to some years ago, gdb could be compiled by a K&R C compiler.
> Now, it can not anymore, and the change seems to be deliberate.

Well, you have to move forward, even if you don't see it
as a step forwad ;-)

> It seems to me that the freedom of the gdb users is now restricted compared
> to the previous versions because of the need of an ISO-C compiler instead
> of any C compiler to compile it.
> 
> And I do not understand why the same reasons that apply to binutils and gcc
> do not hold for gdb.  gdb, because it is better than the debugger you get
> with your operating system, is needed to bootstrap the installation of
> gas, gld, or gcc in the likely case that not everything works well
> the first time.

All major operating systems I know come with a reasonable modern
iso-c compiler (or at least you can get one for it). And even if
this weren't the case, you can always crosscompile gdb on a different
platform (This feature needs more testing anyways ;-)

Just my 0,02 EUR,

  Guenther
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Cc: ezannoni@cygnus.com
Subject: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003050850.DAA10185@indy.delorie.com>
X-SW-Source: 2000-q1/msg00544.html
Content-length: 1150

A comment in event-top.c (inside the change_line_handler function)
says this:

  /* NOTE: this operates on input_fd, not instream. If we are reading
     commands from a file, instream will point to the file. However in
     async mode, we always read commands from a file with editing
     off. This means that the 'set editing on/off' will have effect
     only on the interactive session. */

However, running "gdb < foo" seems to contradict this: I put a
breakpoint in gdb_readline2, and it is never hit.  Am I missing
something?

The problem with this is that if the file `foo' includes a command
which needs a confirmation, the call to fgetc in query will eatup lots
of characters which will never again be seen by the event loop.  In my
case, fgetc read all the file (it was small), so GDB hit EOF and
exited.  I can prevent this from happening by putting "set editing off"
in the input file.  Invoking GDB with --noasync also solves the
problem.

Does this work on Unix?  If so, it would make this a DJGPP-specific
problem.

If this is not DJGPP-specific, then I think _initialize_event_loop
should turn editing off if input_fd is not a tty.
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb@sourceware.cygnus.com
Subject: Re: Updated MAINTAINERS file - work in progress
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002111033.LAA29442@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00221.html
Content-length: 434

At 21:33 10/02/00 -0800, you wrote:
>> Andrew Cagney			ac131313@cygnus.com?
>> Stan Shebs			shebs@cygnus.com?

  Wouldn't it be much more logical to have aliases here ?

  Andrew.Cagney@sourceware.cygnus.com
or even better

  Andrew.Cagney@gdb.fsf.org ??? 


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 hanymorcos@yahoo.com Sat Apr 01 00:00:00 2000
From: Hany Morcos <hanymorcos@yahoo.com>
To: Hany Morcos <hanymorcos@yahoo.com>, gdb@sourceware.cygnus.com
Subject: Re: Debugging a constructor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000225003041.21219.qmail@web3204.mail.yahoo.com>
X-SW-Source: 2000-q1/msg00413.html
Content-length: 686

Got it 
thank you

--- Hany Morcos <hanymorcos@yahoo.com> wrote:
> 
> 
> How do I print the variable values inside
> a constructor?
> 
> I can't use this... Because doesn't exist yet..
> The object hasn't been constructed...
> 
> Then how do I print the value of x??
> 
> class y{
> 
>     public: 
>       y(int* x) {x =
> coreDumpAndGenerateManyHeadaches(); // print x
> inside
> gdb } ;
> };
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: `long double' support for ix86 targets
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00523.html
Content-length: 5450

Hi,

Kevin's changes to findvar.c:extract_floating() and store_floating()
together with some further analysis have convinced me that for all but
one ix86 targets 96-bit long doubles of type &floatformat_i387_ext are
the right thing.  This would give most of the ix86 targets instant
support for long doubles.  It also gives us the opportunity to remove
some ugly bits introduced by people who tried to hack around the
current limitations.

Here are some personal notes I made about this:

   Support for `long double'
   -------------------------

   The majority of i386 targets in GCC have a `long double' that is
   96 bits wide (of which only 80 bits are used, the rest is padding).
   In fact the only exception is OSF/1, where `long double' is equivalent
   to `double' and has only 64 bits.  This length of 96 bits is also
   used in the debugging information generated by the compiler.

   The origional i386 System V ABI specification doesn't say anything about
   `long double', but the new (draft) IA-64 System V ABI specification
   uses a `long double' of 96 bits for things running in 32-bit mode.
   I guess that 32-bit mode is supposed to be provided for compatible
   with IA-32, this implies that 96 bits is supposed to be the standard.

   Therefore, `config/i386/tm-i386.h' should define:

     #define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
     #define TARGET_LONG_DOUBLE_BITS 96

   Targets such as OSF/1 can override this.

   If we do the above, we can make the default "virtual" type of the FPU
   registers `builtin_type_long_double'.  A lot of the Linux cruft for
   dealing with `long double' could be removed.

I intend to check in the following patch in a week or two, but since
this change affects most of the ix86 targets, I'd like to give people
the opportunity to object.

Mark


2000-03-02  Mark Kettenis  <kettenis@gnu.org>

	* config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
	&floatformat_i387_ext.
	(TARGET_LONG_DOUBLE_BITS): Define as 96.
	(REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
	`builtin_type_long_double'.
	(REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
	with zeroes.
	(REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
	(i387_to_double, double_to_i387): Remove prototypes.


Index: config/i386/tm-i386.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-i386.h
--- config/i386/tm-i386.h	2000/02/29 13:28:24	1.2
+++ config/i386/tm-i386.h	2000/03/03 15:00:49
@@ -1,5 +1,5 @@
 /* Macro definitions for GDB on an Intel i[345]86.
-   Copyright (C) 1995, 1996 Free Software Foundation, Inc.
+   Copyright (C) 1995, 1996, 2000 Free Software Foundation, Inc.
 
    This file is part of GDB.
 
@@ -28,6 +28,19 @@ struct type;
 
 #define TARGET_BYTE_ORDER LITTLE_ENDIAN
 
+/* The format used for `long double' on almost all i386 targets is the
+   i387 extended floating-point format.  In fact, of all targets in the
+   GCC 2.95 tree, only OSF/1 does it different, and insists on having
+   a `long double' that's not `long' at all.  */
+
+#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
+
+/* Although the i386 extended floating-point has only 80 significant
+   bits, a `long double' actually takes up 96, probably to enforce
+   alignment.  */
+
+#define TARGET_LONG_DOUBLE_BITS 96
+
 /* Used for example in valprint.c:print_floating() to enable checking
    for NaN's */
 
@@ -229,7 +242,7 @@ extern int i386_register_virtual_size[];
 #define REGISTER_VIRTUAL_TYPE(N)				\
   (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM)	\
    ? lookup_pointer_type (builtin_type_void)			\
-   : IS_FP_REGNUM(N) ? builtin_type_double			\
+   : IS_FP_REGNUM(N) ? builtin_type_long_double			\
    : IS_SSE_REGNUM(N) ? builtin_type_v4sf			\
    : builtin_type_int)
 
@@ -239,25 +252,22 @@ extern int i386_register_virtual_size[];
    that SSE registers need conversion.  Even if we can't find a
    counterexample, this is still sloppy.  */
 #define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n))
-
-/* Convert data from raw format for register REGNUM in buffer FROM
-   to virtual format with type TYPE in buffer TO.  */
-extern void i387_to_double (char *, char *);
 
+/* Convert data from raw format for register REGNUM in buffer FROM to
+   virtual format with type TYPE in buffer TO.  In principle both
+   formats are identical except that the virtual format has two extra
+   bytes appended that aren't used.  We set these to zero.  */
 #define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO)	\
-{								\
-  double val;							\
-  i387_to_double ((FROM), (char *)&val);			\
-  store_floating ((TO), TYPE_LENGTH (TYPE), val);		\
-}
-
-extern void double_to_i387 (char *, char *);
-
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO)		\
-{								\
-  double val = extract_floating ((FROM), TYPE_LENGTH (TYPE));	\
-  double_to_i387((char *)&val, (TO));				\
-}
+  {								\
+    memset ((TO), 0, TYPE_LENGTH (TYPE));			\
+    memcpy ((TO), (FROM), FPU_REG_RAW_SIZE);			\
+  }
+
+/* Convert data from virtual format with type TYPE in buffer FROM to
+   raw format for register REGNUM in buffer TO.  Simply omit the two
+   unused bytes.  */
+#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
+  memcpy ((TO), (FROM), FPU_REG_RAW_SIZE)
 
 /* Print out the i387 floating point state.  */
 #ifdef HAVE_I387_REGS
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C69870.709F@cygnus.com>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <20000307170321.A884@lucon.org> <200003080119.e281Jul00524@delius.kettenis.local> <20000307173547.A1068@lucon.org>
X-SW-Source: 2000-q1/msg00610.html
Content-length: 1507

H . J . Lu wrote:
> 
> On Wed, Mar 08, 2000 at 02:19:56AM +0100, Mark Kettenis wrote:
> >    Date: Tue, 7 Mar 2000 17:03:21 -0800
> >    From: "H . J . Lu" <hjl@lucon.org>
> >    Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
> >    Content-Type: text/plain; charset=us-ascii
> >
> >    > HJ, please stop wasting your time pushing this patch.  The patch has
> >    > several bad points, that you cannot fix without considerable changes
> >    > to the way solib.c handles and caches the link map.
> >
> >    I just pointed out gdb needed to check the unloaded DSOs when handling
> >    the BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK
> >    events. It is a serious bug to me and it should be fixed in 5.0. I
> >    don't care how it is fixed.
> >
> > But I, and I hope most of the other GDB maintainers, do care how it is
> > fixed!
> 
> That is fine with me as long as it is fixed in 5.0. There is no excuse
> not to get gdb to work with dlclose. "I don't like the way it fixes the
> bug" doesn't count unless you can provide a different approach. I
> think it is unreasonable to have a perfect fix for every bug. We can
> work a better one after 5.0 if we don't have the time now.

I'm sorry, but I have to disagree.  I'm not addressing your
patch in particular, but there are many "fixes" that are 
worse than no fix at all.  In fact, GDB is full of them, 
to our (the maintainers) daily regret.  There is never time
to fix it right the second time.

Michael
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Michael Snyder <msnyder@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307161609.B485@lucon.org>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com>
X-SW-Source: 2000-q1/msg00574.html
Content-length: 527

On Tue, Mar 07, 2000 at 03:27:48PM -0800, Michael Snyder wrote:
> I appreciate your helping to find problems with it, and
> I'd like to  know what else in the code you regard as a
> "loose end".  One of my problems is that I'm not really
> an experienced writer of multi-threaded apps -- I'm just
> the person on the GDB team with the most experience with
> GDB multi-thread debugging.

There are 6 multi-thread examples under linuxthreads in glibc 2.
They will be built when you do "make check". Play with them in
gdb.


H.J.
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Z-protocol errors and limts
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mln5btbmy.fsf@jtc.redbacknetworks.com>
References: <Pine.SGI.3.95.1000125201837.17703B-100000@world.std.com>
X-SW-Source: 2000-q1/msg00064.html
Content-length: 1524

>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> I have a few questions related to Z-protocol on implmentation
Quality> on the stub side:
Quality>
Quality> 1. How many soft break point has to be supported ?
Quality>
Quality> 2. How stub tells gdb that it run out of soft break points ?
Quality>
Quality> 3. If stub supports soft break points but does not support
Quality>    hw (or some of hw break points), how it tells gdb about it?

You point out weaknesses in the Z/z specification.

In the debug stub I wrote, I reserved 32 nodes to store breakpoints of
all types and returned a 'EXX' code on all failures (out of breakpoint
nodes, unable to insert breakpoint, etc.).

I picked 32 breakpoints out of thin air.  Based on my experiences, 32
seemed like more than enough.  And if it turned out too be too small,
I could always re-compile the debug agent with a larger number.

When my stub only supported software breakpoints, it returned a 'EXX'
code for hardware breakpoint and watchpoints.  GDB's remote.c handles
such a response as an error (ie. remote_insert_watchpoint(), etc. will
return -1), but I'm not sure this will result in an error message a 
user will be able to interpret correctly

In retrospect, I should have given unique error codes for each
possible error so that GDB could handle errors more inteligently.  

I'm addressing this, and many other shortcomings, in a replacement
protocol I've been designing the last month or so.


        --jtc

-- 
J.T. Conklin
RedBack Networks
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: leedh <leedh@cs.hongik.ac.kr>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Question.....
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000329094518.C17092@visi.com>
References: <38E1B5BA.C555471B@cs.hongik.ac.kr>
X-SW-Source: 2000-q1/msg00836.html
Content-length: 705

On Wed, Mar 29, 2000 at 04:50:19PM +0900, leedh wrote:

> Now, We are willing to connect cygnus GNU debugger toolkit(host
> system-window NT) to angel debugger on EBSA-285 Board(target
> system-strongArm).
> 
> But, cygnus debugger isn't connectted to target system.

You're trying to use gdb to talk to the Angel ROM monitor to
debug ARM software, right?  And you can't get gdb to talk to
the Angel monitor?

1) Make sure you have a current snapshot of gdb -- something
   less than two months old.  Older versions of gdb don't
   handle RDI/ADP as well.

2) What exactly happens when you tell gdb to coneect to the
   Angle ROM monitor using the "target rdi" command?

-- 
Grant Edwards
grante@visi.com
From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000
From: Guenther Grau <Guenther.Grau@marconicomms.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Try out the patch database
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BD61EF.81A4E3C6@marconicomms.com>
References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan> <npem9ulja1.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00476.html
Content-length: 602

Hi,

> > > Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
> > > let me know what you think.

I have a few comments on this.

First of all: great to have a bug database online!

Second, why is the category named gdb-patches instead of gdb?
Is it not intended for people to report bugs? Is it only
for patches?

Third, (but not very important) why do you use persistant
cookies? I don't like cookies und usually disable them,
but I could live with session cookies, if you really insist
on them. But persistent cookies that last for a month are
not what I like.

Thanx,

  Guenther
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Objective-C patches?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bn1nth9gu.fsf@rtl.cygnus.com>
References: <38CF0958.DCEDD532@doc.com> <38D5B417.64A47BC5@cygnus.com>
X-SW-Source: 2000-q1/msg00744.html
Content-length: 272

> I can't speak for Apple so don't believe what follows ...

For more background see:

    http://slashdot.org/articles/00/03/17/1656240.shtml
    http://webx.lists.apple.com/?13@222.lE3famDWjDu^2@.ee90f2e

If anyone wants to help, I'm sure there are ways to do that :-).
From assar@sics.se Sat Apr 01 00:00:00 2000
From: Assar Westerlund <assar@sics.se>
To: gdb@sourceware.cygnus.com
Subject: anoncvs errors?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5l7lgez651.fsf@assaris.sics.se>
X-SW-Source: 2000-q1/msg00191.html
Content-length: 216

Hi, I'm getting this error trying to use anonymous CVS to
:pserver:anoncvs@anoncvs.cygnus.com:/cvs/gdb.

Sorry, you don't have read/write access to the history file /cvs/gdb/CVSROOT/history
Permission denied

/assar
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: scottb@netwinder.org
Cc: msnyder@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Problems with changes to linux-thread.c, gdb_wait.h
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003192243.e2JMhPe00619@delius.kettenis.local>
References: <38D2A8E2.755D235D@netwinder.org>
X-SW-Source: 2000-q1/msg00739.html
Content-length: 482

   Date: Fri, 17 Mar 2000 16:51:30 -0500
   From: Scott Bambrough <scottb@netwinder.org>

   Your changes listed below are causing me two problems on ARM with
   glibc 2.1.3.

They're not exactly *my* changes :-(.

   2000-03-17  Mark Kettenis  <kettenis@gnu.org>

	   * gdb_wait.h: add definitions of WSETSTOP and WSETEXIT for Linux.
	   * linux-thread.c: Use WSETSTOP instead of W_STOPCODE.

Michael, if you rework a patch a bit, could you please put your own
name on it?  

Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Richard Chan <cshihpin@dso.org.sg>
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB supporting namespace std?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A7E3AD.5BE72E9C@cygnus.com>
References: <Pine.LNX.4.10.10001142208380.673-100000@cshihpin.dso.org.sg>
X-SW-Source: 2000-q1/msg00263.html
Content-length: 401

Chan Shih-Ping wrote:
> 
> Does GDB support the use of namespace std::,
> code compiled with -fhonor-std (and an
> appropriately compiled libgcc.a) and using
> std::string s.
> 
> However attempts at using
> print s.size
> 
> gives messages like
> Couldn't find method string::size()

Given that no one has responded, I'd suspect the answer to be no.
It sounds like a good problem to persue.

	Andrew
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Philippe De Muyter <phdm@macqel.be>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DBB76D.65C58273@apple.com>
References: <200003241301.OAA04488@mail.macqel.be>
X-SW-Source: 2000-q1/msg00799.html
Content-length: 1525

Philippe De Muyter wrote:
> 
> Up to some years ago, gdb could be compiled by a K&R C compiler.
> Now, it can not anymore, and the change seems to be deliberate.

Dude, we discussed this over a year ago, and we even tested it by
including an deliberately ISO-only file in 4.18.  Not a single
user reported this as a problem with the 4.18 release, and I was
watching closely for such a complaint.

> It seems to me that the freedom of the gdb users is now restricted compared
> to the previous versions because of the need of an ISO-C compiler instead
> of any C compiler to compile it.
> 
> And I do not understand why the same reasons that apply to binutils and gcc
> do not hold for gdb.  gdb, because it is better than the debugger you get
> with your operating system, is needed to bootstrap the installation of
> gas, gld, or gcc in the likely case that not everything works well
> the first time.

Indeed, I sent our results back to RMS, saying that there didn't seem to
be any reason not to change the GNU coding standards for all GNU tools,
including GCC and binutils.  I don't know if he actually made the
change though.

So I think we've been sufficiently careful to ascertain whether the
modernization was justified, and there is no good reason to try to revive
K&R compat and the additional complexity that goes along with it.  In fact,
I've been a little disappointed that people haven't gone through random source
files, and simplified their sources by stripping out all the now-unneeded
K&R compat bits.

Stan
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: nsd@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002121806.e1CI66F02876@delius.kettenis.local>
References: <38A47E89.3F4674B3@mozilla.org> <882mue$s0f$1@cronkite.cygnus.com>
X-SW-Source: 2000-q1/msg00245.html
Content-length: 745

   From: nsd@cygnus.com (Nick Duffek)
   Date: 12 Feb 2000 04:18:22 GMT

   In article < 38A47E89.3F4674B3@mozilla.org >,

   >There are also various problems with threads.  A lot of times gdb
   >won't exit after the last thread exits because it keeps trying to
   >kill a process which doesn't exist any more.

   I've got a similar report from elsewhere; I'll be checking into it shortly.

As I wrote in a reaction to Chris's message, this may very well be
caused by a bug in LinuxThreads.  I've seen several bug-reports about
apps not exiting after the last thread finished.  Apparently there is
a race of some sort (surprise, surprise), and it may very well be that
debugging with GDB just makes it more likely to trigger the race.

Mark