Re: Dependence on config.status

[Andrew Cagney <ac131313@cygnus.com>]

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