Re: unused parameter warnings

[Jim Blandy <jimb@zwingli.cygnus.com>]

> > Having the top level Makefile.in ``impose'' a specific -W policy is
> > something to discuss with the other projects.
> 
> I'd suggest configuring with
> 
> 	CFLAGS=-g ..../configure

Okay, that makes sense.  Thanks.
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: 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: <npu2iicdra.fsf@zwingli.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/msg00583.html
Content-length: 579

> 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 believe there is such a thing as a correct fix.  And I don't think
they so hard to find that one must always shamble towards correctness.
I think it's fine to reject a patch that one knows has bugs as serious
as the extant code.
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb@sourceware.cygnus.com
Subject: Re: unloading shared objects
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <np7lf6bwp4.fsf@zwingli.cygnus.com>
References: <200003102253.XAA04805@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00687.html
Content-length: 1796

> > Anyway, I'll finish these when I get back, if nobody else does.  I'd
> > love comments on the changes.
> 
> Looks like the way to go. If at all possible, could you adapt my proposed
> changes to avoid casts to/from CORE_ADDR to your patches ?

Sure thing.

> There are at least two more subcases for this case (which should perhaps
> be mentioned in a FIXME), where _something_ needs to happen:
> 
>       - The DSO might have changed in the meantime, in which case we will
> 	have to reread it. Comparing timestamps between GDB's view
> 	of the DSO and the current DSO will detect this case.
>       - The shared object is now loaded to another address, requiring
> 	relocation of the DSO in GDB's symbol tables etc.
> 	This might happen if another DSO increased in size since the
> 	last run, causing a relocation for the current DSO.
> 	Handling this requires comparison between the current objfile
> 	offsets and the computed offsets for the DSO in the inferior.

The shared object list should be emptied each time the inferior is
started, exactly because the address at which a given shared object is
loaded may vary from run to run.  Within a particular process, shared
objects never change address.  We re-read each shared object's symbols
every time it is loaded.  So I think these are handled trivially.


> And for the next round of changes (GDB-17.0 ?):
> 
> Create a layer between GDB's view of DSOs and the target DSOs.
> This would get rid of duplicated solib.c code in osfsolib.c, irix5-nat.c
> and perhaps the awkward DSO handling in rs6000-nat.c. It might also
> allow us to split solib.c properly into SVR4 and non-SVR4 (SunOS 4.x/BSD)
> components.

Absolutely!  Solaris already has an interface for this, modeled after
the thread_db library, which we may want to emulate.
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: Vandervennet Yves <yves.vandervennet@philips.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Some Questions about GDB
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <np66vfr25f.fsf@zwingli.cygnus.com>
References: <200002232139.QAA08859@delysid.gnu.org>
X-SW-Source: 2000-q1/msg00389.html
Content-length: 1295

> Hi there,

Hi!  The best place for questions like this is
gdb@sourceware.cygnus.com.


>     I am trying to find out if it is possible to debug an embedded
> program with gdb running on a workstation.

It certainly is.  Most of the contracts Cygnus took were to support
embedded systems of some sort or another.  (We expect things to remain
the same under the Red Hat name.)

>    * which distribution of gdb is needed ?

Any distribution of GDB should work.  Certainly the ones available
from the FSF or from sourceware.cygnus.com do.

>    * what is the protocol used ? Serial line ? TCP/IP ?

There are many protocols supported.  GDB can talk over a serial line
or to an arbitrary host and TCP port.  GDB has its own remote
protocol, which works fine, which is fully documented in the GDB
manual.  Also, GDB knows how to talk to many different kinds of ROM
monitors --- as far as the monitor is concerned, GDB is just a very
fast typist.

>    * what is the program (or piece of code) that has to run on the
>      target machine ?

You'll either need a ROM monitor GDB knows how to talk to, or you can
write a simple stub.  The GDB distribution includes several sample
stubs you can modify to suit your needs.  All this is described in the
GDB manual.

(Gosh, I love questions like that.)
From davidwilliams@ozemail.com.au Sat Apr 01 00:00:00 2000
From: David Williams <davidwilliams@ozemail.com.au>
To: Serge Nikulin <nikulin@actsw.amat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: How to set RS232 speed in gdb in WinNT?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E538DF.ED6289D6@ozemail.com.au>
References: <003e01bf9b69$afc0c220$35758798@mis.amat.com>
X-SW-Source: 2000-q1/msg00853.html
Content-length: 1045

Use -b command line option to change baud rate

eg.     gdb -b 115200
to set baud rate 115200 baud.
Dave.

Serge Nikulin wrote:

> Hi,
>
> I use gdb for remote debugging of m68k target, compiled with MRI
> <--host=i686-pc-cygwin32 --target=m68k-motorola-ieee>
> Native MRI' X-Ray debugger does not support our home-made RTOS.
> GDB works but I have few questions.
>
> 1) Currently ieee-695 bfd section is not connected to gdb, so I work without
> src.
>     I've checked examples of coff and aout conections and it does not look
> as a 1-day job for me
>     (including the fact that ieee-695 support in bfd is incomplete).
>     Does anyone have ieee + gdb experience?
>
> 2) In my gdb session under WinNT I use command "target remote com1"
> In this case gdb connects to COM1 at 9600 baud. I'd like to change this
> speed (say, to 38400) but I can't. I've changed default speed for COM1 in
> WinNT's control panel but it did not help. It looks like I have to pass that
> speed to cygwin.dll somehow. How can I do that?
>
> Thanks!
>
> Serge.