Re: Variable "foo" is not available

["Eli Zaretskii" <eliz at gnu dot org>]

> Date: Fri, 1 Apr 2005 12:19:47 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> It means, literally, that the value is not available.  The compiler has
> not saved it in somewhere that is still accessible, or has not told GDB
> properly where it was saved.

The compiler was GCC in this case.  Is this a GCC bug?  I cannot
imagine how we would be able to explain the fact that _every_ frame in
the backtrace has this message about some of the function parameters,
other than by either a GCC bug or a GDB bug.

> There's always a chance that it's a GDB bug, of course.

Can you suggest a way for Rainer to see if this a GDB bug?  For
example, could he somehow use readelf or similar tools to give some
information that would help us determine whether this is a GDB bug?

Rainer, could you please use the GDB "up" command a few times, and
after each time type "info args" and see whether that does give you
the arguments of the function call in that frame?

> What this normally means is that you are using optimization, and the value
> of tag is not referenced after the function call, so the compiler did
> not save it anywhere.

If this happens frequently with GCC, we should document it in the
manual.

Rainer, could you please tell exactly which compiler switches were
used to build that version of Emacs?

In any case, it is rather unhelpful for the compiler to behave that
way, since it means debugging optimized programs, once a flagship of
GCC features wrt other compilers, is now very hard or even
impractical.  If this is intended behavior, I'd say it's a bad
misfeature.

I also find the string we print in this case too long.  (You say that
in current CVS the output is a little nicer, but I don't see any
changes in CVS's dwarf2loc.c, which prints this, compared with GDB
6.1; could you state in more detail which change you had in mind?)

Something like

> #61 0x000000000054c960 in internal_catch (tag=<N/A>)

would be much better, IMHO.

> and following function arguments won't be chopped off.

That would be certainly better, but again, I don't see that change in
the current CVS.

In any case, if Rainer could build the latest snapshot of GDB and see
if the values of the rest of the function call arguments are printed
(as opposed to all of them generating the "not available" message), it
would perhaps tell us something about the underlying problem.