Re: Dependence on config.status

Re: Dependence on config.status

[Eli Zaretskii]

The following changes remove the dependency of GDB on config.status.

If people would still like to have automatic recompile when [ntx]m.h
are linked to different files, I think the correct way is to make
configure define [NTX]M_FILE symbols on config.h by using the values
of ${nativefile}, ${targetfile}, and ${hostfile}, which it already
computes.


2000-03-03  Eli Zaretskii  <eliz@is.elta.co.il>

	gdb/Makefile.in (defs_h): Don't depend on config.status.  (This
	is only needed when [ntx]m.h headers are linked to another set
	of files, in which case they should "make clean".)

--- gdb/Makefile.i~0	Tue Feb 22 10:52:06 2000
+++ gdb/Makefile.in	Fri Mar  3 13:52:30 2000
@@ -495,7 +496,7 @@
 gdbcmd_h =	gdbcmd.h $(command_h)
 
 call_cmds_h =	call-cmds.h
-defs_h =	defs.h xm.h tm.h nm.h config.status config.h gdbarch.h ui-file.h
+defs_h =	defs.h xm.h tm.h nm.h config.h gdbarch.h ui-file.h
 
 top_h =		top.h
 inferior_h =	inferior.h $(breakpoint_h)
From eliz@delorie.com Fri Mar 03 23:03:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: muller@cerbere.u-strasbg.fr
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 23:03:00 -0000
Message-id: <200003040703.CAA08165@indy.delorie.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00070.html
Content-length: 592

> I have written for DJGPP target a relatively small patch.
> It allows to read memory from another selector
> this was very useful for me when I tried to debug the debugger itself and 
> when I added exception support fro GDB on DJGPP !

I have this patch on my disk, and will review it when I have time.

>   Is such kind of patch too specific to have any chance to get accepted ?
> I don't know if it could be of any use for other processors or operating
> system !!

I second the question.

In any case, I understand that there's no problem to add architecture-
specific commands, right?
From eliz@delorie.com Fri Mar 03 23:04:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 23:04:00 -0000
Message-id: <200003040704.CAA08168@indy.delorie.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <200003031240.e23CeRn00162@delius.kettenis.local>
X-SW-Source: 2000-03/msg00071.html
Content-length: 170

> The suggested syntax could probably be
> improved, since "xx" isn't very descriptive.  People with bright ideas?

How about "x/seg=SEG OFFSET"?  Or simply "x SEG:OFF"?
From eliz@delorie.com Fri Mar 03 23:07:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: muller@cerbere.u-strasbg.fr, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 23:07:00 -0000
Message-id: <200003040706.CAA08171@indy.delorie.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <38BFB50A.606036CF@cygnus.com>
X-SW-Source: 2000-03/msg00072.html
Content-length: 232

> The theory is that if ``CORE_ADDR'' is made in to a pretend object
> (ISO-C remember :-) and then the rest falls out....  As they say, the
> proof is left as an exercise to the reader.

Sorry, I don't follow.  Can you elaborate?

Re: Dependence on config.status

[Andrew Cagney]

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?

	Andrew
From martin@loewis.home.cs.tu-berlin.de Sat Mar 04 01:47:00 2000
From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
To: tjw@omnigroup.com
Cc: shebs@apple.com, gdb@sourceware.cygnus.com, gcc@gcc.gnu.org
Subject: Re: Should GCC tell GDB about its optimizations?
Date: Sat, 04 Mar 2000 01:47:00 -0000
Message-id: <200003040942.KAA13582@loewis.home.cs.tu-berlin.de>
References: <0003031702.AA550283@electabuzz>
X-SW-Source: 2000-03/msg00074.html
Content-length: 863

>   What sort of squirrelly behavior are you talking about exactly?  If it is 
> just the typical problem where GCC reuses register's and stack locations 
> when variables lifetime's are over, this would seem like a gdb problem, not 
> a GCC problem.

I don't know what problem Stan is talking about, but I know there are
other problems:

- If  a function  is inlined,  single-stepping will  get you  into the
  function source code. However, it won't appear in the backtrace, and
  invoking 'fin' will do the wrong thing.

- Again, in inlining, the compiler will not put information about
  function parameters into the stabs if the parameters are
  optimized-away.

- The same holds for local variables - if they are eliminated, gdb
  won't know about them - they just don't exist in the debug
  information (or, in the code, for that matter)

Regards,
Martin