Variable "foo" is not available

Variable "foo" is not available

[Reiner Steib]

Hi,

while running Emacs under gdb, I got the backtrace shown below with
many messages like `vector=Variable "vector" is not available'.
Eli Zaretskii suggested[1] to ask here what this means.

The gdb version is 6.2.1 (from SuSE Linux 9.2 AMD 64).  The gdb
session is still running, so I can provide more information if
requested.

Please Cc me on replies, I'm not subscribed to the list.

Bye, Reiner.

[1] http://thread.gmane.org/v9wtrniolo.fsf%40marauder.physik.uni-ulm.de

--8<---------------cut here---------------start------------->8---
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library
 "/lib64/tls/libthread_db.so.1".

DISPLAY = :0.0
TERM = screen
Breakpoint 1 at 0x4e2f90: file [...]/emacs/src
/emacs.c, line 456.
Breakpoint 2 at 0x4bb620: file [...]/emacs/src
/xterm.c, line 7791.
(gdb) cd ~
(gdb) r -name Gnus -xrm 'Emacs.toolBar:1' -f gnus
Starting program: [...]/x86_64/src/emacs -name Gnus -xrm 'Emacs.toolBar:1' -f gnus
[Thread debugging using libthread_db enabled]
[New Thread 182940272320 (LWP 2719)]
Detaching after fork from child process 2722.
[...]
Detaching after fork from child process 19927.
[Switching to Thread 182940272320 (LWP 2719)]

Breakpoint 1, abort ()
    at [...]/emacs/src/emacs.c:456
456     {
(gdb) xbacktrace 
[...]
(gdb) bt
#0  abort () at [...]/emacs/src/emacs.c:456
#1  0x0000000000539245 in Fgarbage_collect ()
    at [...]/emacs/src/alloc.c:4742
#2  0x000000000057a1d4 in Fbyte_code (bytestr=9727377, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:531
#3  0x000000000054d59d in funcall_lambda (fun=29850740, nargs=1, 
    arg_vector=0x7fbfffb198)
    at [...]/emacs/src/eval.c:2974
#4  0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#5  0x0000000000579cc9 in Fbyte_code (bytestr=9727377, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#6  0x000000000054d150 in Feval (form=Variable "form" is not available.
)
    at [...]/emacs/src/eval.c:2138
#7  0x000000000054fcb8 in Fcondition_case (args=Variable "args" is not available.
)
    at [...]/emacs/src/eval.c:1332
#8  0x000000000057925f in Fbyte_code (bytestr=29655265, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:864
#9  0x000000000054d59d in funcall_lambda (fun=29688788, nargs=3, 
    arg_vector=0x7fbfffb6f8)
    at [...]/emacs/src/eval.c:2974
#10 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#11 0x0000000000579cc9 in Fbyte_code (bytestr=11494737, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#12 0x000000000054d59d in funcall_lambda (fun=29857172, nargs=3, 
    arg_vector=0x7fbfffb8a8)
    at [...]/emacs/src/eval.c:2974
#13 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#14 0x0000000000579cc9 in Fbyte_code (bytestr=25161265, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#15 0x000000000054d59d in funcall_lambda (fun=29855572, nargs=2, 
    arg_vector=0x7fbfffba78)
    at [...]/emacs/src/eval.c:2974
#16 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#17 0x0000000000579cc9 in Fbyte_code (bytestr=25161313, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#18 0x000000000054d150 in Feval (form=Variable "form" is not available.
)
    at [...]/emacs/src/eval.c:2138
#19 0x000000000054fcb8 in Fcondition_case (args=Variable "args" is not available.
)
    at [...]/emacs/src/eval.c:1332
#20 0x000000000057925f in Fbyte_code (bytestr=29643537, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:864
#21 0x000000000054d150 in Feval (form=Variable "form" is not available.
)
    at [...]/emacs/src/eval.c:2138
#22 0x000000000054c960 in internal_catch (tag=Variable "tag" is not available.
)
    at [...]/emacs/src/eval.c:1144
#23 0x00000000005792a9 in Fbyte_code (bytestr=29703713, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:849
#24 0x000000000054d59d in funcall_lambda (fun=29708644, nargs=4, 
    arg_vector=0x7fbfffc318)
    at [...]/emacs/src/eval.c:2974
#25 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#26 0x0000000000579cc9 in Fbyte_code (bytestr=25161313, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#27 0x000000000054d59d in funcall_lambda (fun=25163556, nargs=3, 
    arg_vector=0x7fbfffc4c8)
    at [...]/emacs/src/eval.c:2974
#28 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#29 0x0000000000579cc9 in Fbyte_code (bytestr=25161313, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#30 0x000000000054d59d in funcall_lambda (fun=29606004, nargs=3, 
    arg_vector=0x7fbfffc678)
    at [...]/emacs/src/eval.c:2974
#31 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#32 0x0000000000579cc9 in Fbyte_code (bytestr=25161313, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#33 0x000000000054d59d in funcall_lambda (fun=25163556, nargs=3, 
    arg_vector=0x7fbfffc828)
    at [...]/emacs/src/eval.c:2974
#34 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#35 0x0000000000579cc9 in Fbyte_code (bytestr=26679281, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#36 0x000000000054d59d in funcall_lambda (fun=25959284, nargs=1, 
    arg_vector=0x7fbfffc9d8)
    at [...]/emacs/src/eval.c:2974
#37 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#38 0x0000000000579cc9 in Fbyte_code (bytestr=25161265, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#39 0x000000000054d59d in funcall_lambda (fun=25961892, nargs=3, 
    arg_vector=0x7fbfffcb88)
    at [...]/emacs/src/eval.c:2974
#40 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#41 0x0000000000579cc9 in Fbyte_code (bytestr=26678705, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#42 0x000000000054d59d in funcall_lambda (fun=26442260, nargs=6, 
    arg_vector=0x7fbfffcd48)
    at [...]/emacs/src/eval.c:2974
---Type <return> to continue, or q <return> to quit---
#43 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#44 0x0000000000579cc9 in Fbyte_code (bytestr=26678705, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#45 0x000000000054d59d in funcall_lambda (fun=26439572, nargs=7, 
    arg_vector=0x7fbfffcf08)
    at [...]/emacs/src/eval.c:2974
#46 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#47 0x0000000000579cc9 in Fbyte_code (bytestr=26678705, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#48 0x000000000054d59d in funcall_lambda (fun=26681268, nargs=2, 
    arg_vector=0x7fbfffd0c8)
    at [...]/emacs/src/eval.c:2974
#49 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#50 0x0000000000579cc9 in Fbyte_code (bytestr=10171233, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#51 0x000000000054d59d in funcall_lambda (fun=26681684, nargs=1, 
    arg_vector=0x7fbfffd268)
    at [...]/emacs/src/eval.c:2974
#52 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#53 0x0000000000579cc9 in Fbyte_code (bytestr=10171233, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
#54 0x000000000054d59d in funcall_lambda (fun=37322420, nargs=1, 
    arg_vector=0x7fbfffd468)
    at [...]/emacs/src/eval.c:2974
#55 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
#56 0x000000000054a607 in Fcall_interactively (function=26577473, 
    record_flag=9609249, keys=48830452)
    at [...]/emacs/src/callint.c:884
#57 0x00000000004e8124 in Fcommand_execute (cmd=Variable "cmd" is not available.
)
    at [...]/emacs/src/keyboard.c:9697
#58 0x00000000004f4504 in command_loop_1 ()
    at [...]/emacs/src/keyboard.c:1792
#59 0x000000000054c811 in internal_condition_case (
    bfun=0x4f4130 <command_loop_1>, handlers=9720769, 
    hfun=0x4ee770 <cmd_error>)
    at [...]/emacs/src/eval.c:1385
#60 0x00000000004ed9fa in command_loop_2 ()
    at [...]/emacs/src/keyboard.c:1319
#61 0x000000000054c960 in internal_catch (tag=Variable "tag" is not available.
)
    at [...]/emacs/src/eval.c:1144
#62 0x00000000004ee408 in command_loop ()
    at [...]/emacs/src/keyboard.c:1298
#63 0x00000000004ee4a1 in recursive_edit_1 ()
    at [...]/emacs/src/keyboard.c:991
#64 0x00000000004ee5ce in Frecursive_edit ()
    at [...]/emacs/src/keyboard.c:1052
#65 0x00000000004e3dcd in main (argc=7, argv=0x7fbfffdfe8)
    at [...]/emacs/src/emacs.c:1767
--8<---------------cut here---------------end--------------->8---

Re: Variable "foo" is not available

[Daniel Jacobowitz]

On Fri, Apr 01, 2005 at 06:39:45PM +0200, Reiner Steib wrote:
> Hi,
> 
> while running Emacs under gdb, I got the backtrace shown below with
> many messages like `vector=Variable "vector" is not available'.
> Eli Zaretskii suggested[1] to ask here what this means.
> 
> The gdb version is 6.2.1 (from SuSE Linux 9.2 AMD 64).  The gdb
> session is still running, so I can provide more information if
> requested.

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.

(There's always a chance that it's a GDB bug, of course.  But that's
what the message is intended to mean.)

If you use a March CVS snapshot of GDB, the output will be a little
nicer, and following function arguments won't be chopped off.

> #61 0x000000000054c960 in internal_catch (tag=Variable "tag" is not available.
> )
>     at [...]/emacs/src/eval.c:1144

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Variable "foo" is not available

[Eli Zaretskii]

> 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.

Re: Variable "foo" is not available

[Reiner Steib]

On Sat, Apr 02 2005, Eli Zaretskii wrote:

> 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?

I will do this when I'm back in the office.

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

I didn't specify any compiler related configure arguments (only
--prefix, --with-gtk and --exec-prefix) so I use the default options
from Emacs' built system:

,----[ src/Makefile ]
| CC=gcc
| CPP=gcc -E
| CFLAGS=-g -O2
| CPPFLAGS=-D_BSD_SOURCE  
| LDFLAGS= -Wl,-znocombreloc -L/usr/X11R6/lib64
`----

> 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.

This problem is not reproducible.  It's the first time I got those
`Variable "foo" is not available' messages when running Emacs under
gdb (see my previous reports on emacs-pretest).  Is it possible to
detach from this session from gdb and re-attach it to the snapshot
gdb?

Bye, Reiner                ...without any `a' in his name.  ;-)
-- 
PGP key available                  http://rsteib.home.pages.de/

Re: Variable "foo" is not available

[Daniel Jacobowitz]

On Sat, Apr 02, 2005 at 12:45:21PM +0300, Eli Zaretskii wrote:
> > 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.

Not every frame did.  Most of the frames did, but they only represent a
tiny handful of different functions.

> > 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?

You can use readelf to work it out.  However, it requires passing
familiarity with the DWARF specification.  The GDB code for handling
location lists is really not especially complicated; I don't expect
problems in it.

> 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.

This is not a change in compiler behavior, in any way.  These are the
cases which would have printed garbage using any previous GCC release.
Backtraces for optimized code have always been unreliable.

GCC does not take debugability into account at -O2 where it would
compromise any performance optimization; that's what -O2 asked for.

> 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?)

Only loclist_tracepoint_var_ref prints this message any more, assuming
you are looking at a current version of the file.

2005-02-28  Daniel Jacobowitz  <dan@codesourcery.com>

        * dwarf2loc.c (loclist_read_variable): Set optimized_out
        instead of reporting an error.
        * valprint.c (value_check_printable): New function.
        (common_val_print): New function.  Use value_check_printable.
        (value_print): Use value_check_printable.
        * value.h (common_val_print): Add prototype.

	...


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Variable "foo" is not available

[Daniel Jacobowitz]

On Sat, Apr 02, 2005 at 03:52:56PM +0200, Reiner Steib wrote:
> This problem is not reproducible.  It's the first time I got those
> `Variable "foo" is not available' messages when running Emacs under
> gdb (see my previous reports on emacs-pretest).  Is it possible to
> detach from this session from gdb and re-attach it to the snapshot
> gdb?

Yes - it will run when you detach, though.  The commands are "detach"
and "attach".  Who'd've guessed?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Variable "foo" is not available

[Eli Zaretskii]

> Date: Sat, 2 Apr 2005 09:26:40 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> 
> > 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.
> 
> Not every frame did.  Most of the frames did, but they only represent a
> tiny handful of different functions.

9 different functions were reported with such arguments.  IMHO, that's
too many for a rare situation.

Moreover, Rainer says that he never saw such messages before in
debugging Emacs, even though a typical Emacs backtrace always shows
many invocations of these very functions (they are basic primitives of
the Lisp interpreter, and Emacs runs Lisp code most of the time).

> > 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.
> 
> This is not a change in compiler behavior, in any way.  These are the
> cases which would have printed garbage using any previous GCC release.
> Backtraces for optimized code have always been unreliable.
> 
> GCC does not take debugability into account at -O2 where it would
> compromise any performance optimization; that's what -O2 asked for.

It sounds like we were using 2 different compilers.  My experience
with GCC, based on many years, is that -O2 optimized code can be
debugged quite well, as soon as you get accustomed to the execution
thread jumping back and forth due to code rearrangements.  In any
real-life program with good code quality, the fraction of cases where
a variable gets optimized away is very small.

> Only loclist_tracepoint_var_ref prints this message any more, assuming
> you are looking at a current version of the file.

Ah, okay.  I looked at the remaining string and assumed that this is
what Rainer sees.  Sorry.

Re: Variable "foo" is not available

[Daniel Jacobowitz]

On Sat, Apr 02, 2005 at 09:13:06PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Apr 2005 09:26:40 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> > 
> > > 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.
> > 
> > Not every frame did.  Most of the frames did, but they only represent a
> > tiny handful of different functions.
> 
> 9 different functions were reported with such arguments.  IMHO, that's
> too many for a rare situation.

I didn't say it was a rare situation.

> Moreover, Rainer says that he never saw such messages before in
> debugging Emacs, even though a typical Emacs backtrace always shows
> many invocations of these very functions (they are basic primitives of
> the Lisp interpreter, and Emacs runs Lisp code most of the time).

I would assume he's using a newer compiler than he used to.

> > > 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.
> > 
> > This is not a change in compiler behavior, in any way.  These are the
> > cases which would have printed garbage using any previous GCC release.
> > Backtraces for optimized code have always been unreliable.
> > 
> > GCC does not take debugability into account at -O2 where it would
> > compromise any performance optimization; that's what -O2 asked for.
> 
> It sounds like we were using 2 different compilers.  My experience
> with GCC, based on many years, is that -O2 optimized code can be
> debugged quite well, as soon as you get accustomed to the execution
> thread jumping back and forth due to code rearrangements.  In any
> real-life program with good code quality, the fraction of cases where
> a variable gets optimized away is very small.

This definitely has not been my experience since the beginning of the
3.x series; it was more true in the 2.x series, when GCC's optimizers
were much weaker.

As I said, it is a design goal for GCC to optimize efficiently
regardless of debugability when you ask for optimization.  It's gotten
better at that over the years.  Dwarf supports various sophisticated
mechanisms for debugging optimized code; GDB supports almost none of
them.

It's easy to not notice the problem with earlier versions of GCC. On
non-DWARF targets or old versions, the variables will appear to be
available - even if their correct values no longer exist in memory.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Variable "foo" is not available

[Eli Zaretskii]

> Date: Sat, 2 Apr 2005 13:40:23 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> 
> > 9 different functions were reported with such arguments.  IMHO, that's
> > too many for a rare situation.
> 
> I didn't say it was a rare situation.

If it isn't rare, we should do something about it, I think.

> It's easy to not notice the problem with earlier versions of GCC.

I'm using GCC 3.x since the year 2001, and the DWARF 2 debug info as
the default since more than a year ago.  I think this is long enough
not to dismiss my experience.

Anyway, I don't really understand what is your intent.  Are you saying
that this is what we should expect from optimized code in GDB, and
that nothing should or could be done about it?

> On non-DWARF targets or old versions, the variables will appear to
> be available - even if their correct values no longer exist in
> memory.

We are talking about function call arguments here, not just about any
local variables.  Can you tell what compiler optimizations could cause
what Reiner reported: that the first argument is available to GDB, but
the second is not?

Re: Variable "foo" is not available

[Daniel Jacobowitz]

On Sat, Apr 02, 2005 at 11:54:08PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Apr 2005 13:40:23 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> > 
> > > 9 different functions were reported with such arguments.  IMHO, that's
> > > too many for a rare situation.
> > 
> > I didn't say it was a rare situation.
> 
> If it isn't rare, we should do something about it, I think.
> 
> > It's easy to not notice the problem with earlier versions of GCC.
> 
> I'm using GCC 3.x since the year 2001, and the DWARF 2 debug info as
> the default since more than a year ago.  I think this is long enough
> not to dismiss my experience.
> 
> Anyway, I don't really understand what is your intent.  Are you saying
> that this is what we should expect from optimized code in GDB, and
> that nothing should or could be done about it?

What are you suggesting we do about it?  There are only two options:
make the argument remain available, which carries a performance
penalty, or politely inform the user that it is unavailable.  The user
asked for no performance penalties.

I'm not trying to dismiss your experience; but I've worked on this code
in the compiler, and it's just not designed to do what you're
expecting.

> > On non-DWARF targets or old versions, the variables will appear to
> > be available - even if their correct values no longer exist in
> > memory.
> 
> We are talking about function call arguments here, not just about any
> local variables.  Can you tell what compiler optimizations could cause
> what Reiner reported: that the first argument is available to GDB, but
> the second is not?

Very easily.  Suppose you have two incoming arguments in registers; GCC
will do this automatically for static functions even on i386, which
normally uses a stack convention.  The first is used after a function
call, so it is preserved by saving it to the stack.  The second is not
used after the function call, so the compiler has no reason to allocate
a save slot for it, and no reason to store it to memory before the
function call.

With stack-based argument passing, GCC may be claiming an argument is
unavailable when the function's local copy is dead, when a copy still
exists on the stack somewhere.  I don't know if it will do that or not.
GDB can not assume that the argument is available in the incoming stack
slot, since it could be reused for other data.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Variable "foo" is not available

[Reiner Steib]

On Sat, Apr 02 2005, Daniel Jacobowitz wrote:

> On Sat, Apr 02, 2005 at 09:13:06PM +0300, Eli Zaretskii wrote:
>> Moreover, Rainer says that he never saw such messages before in
>> debugging Emacs, even though a typical Emacs backtrace always shows
>> many invocations of these very functions (they are basic primitives of
>> the Lisp interpreter, and Emacs runs Lisp code most of the time).
>
> I would assume he's using a newer compiler than he used to.

Looking up my previous reports, I found that in fact I had this
messages in the backtraces often (I didn't remember it, though.  Sorry
for the wrong information.):

http://thread.gmane.org/v9zmygcz60.fsf_-_@marauder.physik.uni-ulm.de
http://thread.gmane.org/v9oeewweoh.fsf@marauder.physik.uni-ulm.de
http://thread.gmane.org/v9wtthhk62.fsf@marauder.physik.uni-ulm.de
http://thread.gmane.org/v9psytbyyc.fsf@marauder.physik.uni-ulm.de
http://thread.gmane.org/v98y4lds4g.fsf@marauder.physik.uni-ulm.de
http://thread.gmane.org/v9wtrniolo.fsf@marauder.physik.uni-ulm.de

All these were after my upgrade from SuSE 8.2 (probably: gcc 3.3
20030226 (prerelease); gdb-5.3) to SuSE 9.2 (gcc 3.3.4 (pre 3.3.5
20040809)).  I also switched to AMD 64bit.

Bye, Reiner.
-- 
PGP key available                  http://rsteib.home.pages.de/

Re: Variable "foo" is not available

[Eli Zaretskii]

> Date: Sat, 2 Apr 2005 16:05:42 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> 
> > We are talking about function call arguments here, not just about any
> > local variables.  Can you tell what compiler optimizations could cause
> > what Reiner reported: that the first argument is available to GDB, but
> > the second is not?
> 
> Very easily.  Suppose you have two incoming arguments in registers; GCC
> will do this automatically for static functions even on i386, which
> normally uses a stack convention.  The first is used after a function
> call, so it is preserved by saving it to the stack.  The second is not
> used after the function call, so the compiler has no reason to allocate
> a save slot for it, and no reason to store it to memory before the
> function call.

The functions present in Reiner's backtraces are not static, they are
external, with the exception of funcall_lambda.  I don't have access
to an x86_64 machine, but at least on an IA32 x86 architecture the
code produced by GCC 3.4.3 for these function calls is quite
straightforward (see one example below), and with GDB 6.3 I couldn't
reproduce the "arg not available" message.

> With stack-based argument passing, GCC may be claiming an argument is
> unavailable when the function's local copy is dead, when a copy still
> exists on the stack somewhere.  I don't know if it will do that or not.
> GDB can not assume that the argument is available in the incoming stack
> slot, since it could be reused for other data.

What, if any, would be the expression of this in the machine code?

Also, I don't quite understand how can a stack slot of a function call
argument be reused before the function returns.  Isn't that slot
outside the function's frame?  Reusing it would be a violation of the
ABI, right?

Here's the disassembly of one of the frames from Reiner's backtrace:
funcall_lambda calls Fbyte_code.  I disassembled on a 32-bit x86
machine (Reiner, perhaps you could show the disassembly on yours).
The source code is:

      val = Fbyte_code (AREF (fun, COMPILED_BYTECODE),
			AREF (fun, COMPILED_CONSTANTS),
			AREF (fun, COMPILED_STACK_DEPTH));
    }

  return unbind_to (count, val);

Reiner's backtrace is:

#2  0x000000000057a1d4 in Fbyte_code (bytestr=9727377, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:531
#3  0x000000000054d59d in funcall_lambda (fun=29850740, nargs=1, 
    arg_vector=0x7fbfffb198)
    at [...]/emacs/src/eval.c:2974

Here's the disassembly from my machine, with the PC location marked
by "<<<<<<":

0x000c219e <funcall_lambda+510>:        push   %eax
0x000c219f <funcall_lambda+511>:        mov    0x14(%ebx),%edi
0x000c21a2 <funcall_lambda+514>:        push   %edi
0x000c21a3 <funcall_lambda+515>:        mov    0x10(%ebx),%esi
0x000c21a6 <funcall_lambda+518>:        push   %esi
0x000c21a7 <funcall_lambda+519>:        mov    0xc(%ebx),%ebx
0x000c21aa <funcall_lambda+522>:        push   %ebx
0x000c21ab <funcall_lambda+523>:        call   0xed130 <Fbyte_code>
0x000c21b0 <funcall_lambda+528>:        pop    %edx  <<<<<<
0x000c21b1 <funcall_lambda+529>:        pop    %ecx
0x000c21b2 <funcall_lambda+530>:        push   %eax
0x000c21b3 <funcall_lambda+531>:        mov    0xffffffec(%ebp),%eax
0x000c21b6 <funcall_lambda+534>:        push   %eax
0x000c21b7 <funcall_lambda+535>:        call   0xc0dc0 <unbind_to>
0x000c21bc <funcall_lambda+540>:        jmp    0xc201c <funcall_lambda+124>

This is quite traditional stack-based argument passing, unless I'm
missing something.

The code produced for the call to funcall_lambda (not shown) does pass
some arguments via registers, but I still am able to see all the
arguments in the backtrace.

Re: Variable "foo" is not available

[Mark Kettenis]

   Date: Mon, 04 Apr 2005 08:10:00 +0300
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Sat, 2 Apr 2005 16:05:42 -0500
   > From: Daniel Jacobowitz <drow@false.org>
   > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
   > 
   > > We are talking about function call arguments here, not just about any
   > > local variables.  Can you tell what compiler optimizations could cause
   > > what Reiner reported: that the first argument is available to GDB, but
   > > the second is not?
   > 
   > Very easily.  Suppose you have two incoming arguments in registers; GCC
   > will do this automatically for static functions even on i386, which
   > normally uses a stack convention.  The first is used after a function
   > call, so it is preserved by saving it to the stack.  The second is not
   > used after the function call, so the compiler has no reason to allocate
   > a save slot for it, and no reason to store it to memory before the
   > function call.

   The functions present in Reiner's backtraces are not static, they are
   external, with the exception of funcall_lambda.  I don't have access
   to an x86_64 machine, but at least on an IA32 x86 architecture the
   code produced by GCC 3.4.3 for these function calls is quite
   straightforward (see one example below), and with GDB 6.3 I couldn't
   reproduce the "arg not available" message.

amd64 passes arguments in registers by default.  That makes it much
more likely that an argument is discarded if it isn't needed anymore
in order for the compiler to re-use the register.

Mark

Re: Variable "foo" is not available

[Daniel THOMPSON]

Eli Zaretskii wrote:
>>Date: Sat, 2 Apr 2005 16:05:42 -0500
>>From: Daniel Jacobowitz <drow@false.org>
>>Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
>>
>>
>>>We are talking about function call arguments here, not just about any
>>>local variables.  Can you tell what compiler optimizations could cause
>>>what Reiner reported: that the first argument is available to GDB, but
>>>the second is not?
>>
>>Very easily.  Suppose you have two incoming arguments in registers; GCC
>>will do this automatically for static functions even on i386, which
>>normally uses a stack convention.  The first is used after a function
>>call, so it is preserved by saving it to the stack.  The second is not
>>used after the function call, so the compiler has no reason to allocate
>>a save slot for it, and no reason to store it to memory before the
>>function call.
> 
> 
> The functions present in Reiner's backtraces are not static, they are
> external, with the exception of funcall_lambda.  I don't have access
> to an x86_64 machine, but at least on an IA32 x86 architecture the
> code produced by GCC 3.4.3 for these function calls is quite
> straightforward (see one example below), and with GDB 6.3 I couldn't
> reproduce the "arg not available" message.
> 
> 
>>With stack-based argument passing, GCC may be claiming an argument is
>>unavailable when the function's local copy is dead, when a copy still
>>exists on the stack somewhere.  I don't know if it will do that or not.
>>GDB can not assume that the argument is available in the incoming stack
>>slot, since it could be reused for other data.
> 
> 
> What, if any, would be the expression of this in the machine code?
> 
> Also, I don't quite understand how can a stack slot of a function call
> argument be reused before the function returns.  Isn't that slot
> outside the function's frame?  Reusing it would be a violation of the
> ABI, right?

I doubt it.

The following C is perfectly valid.

void foo(int a, int b, int c, int d)
{
	a = b + c;
	printf("a+d = %d\n", a, d);
	printf("b = %d\n", b);
}

On modern architectures with a decent number of registers (including 
IIRC the x86-64) a, b and c will be passed in registers rather than on 
the stack.

Just as it is entirely legal for the C code to overwrite a it is 
entirely legal that after the addition the compiler can choose to 
overwrite c since it is no longer used. In the case above it will be 
overwritten implicitly by the first call to printf. The resultant code 
will be faster because there will be no code in foo to store c to the 
stack before calling the first printf.

I suspect as Mr. Jacobowitz says on some of the older compiler/debugger 
combos on a register rich archictecture there will be no warning but if 
you examine the value of c between the printfs when c would have a 
garbage value. The current behavior is clearly superior.

-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?

Re: Variable "foo" is not available

[Reiner Steib]

On Sat, Apr 02 2005, Eli Zaretskii wrote:

> 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?

--8<---------------cut here---------------start------------->8---
(gdb) up
#1  0x0000000000539245 in Fgarbage_collect ()
    at [...]/emacs/src/alloc.c:4742
4742                stack_copy = (char *) xrealloc (stack_copy, (stack_copy_size = i));
(gdb) info args
No arguments.
(gdb) up
#2  0x000000000057a1d4 in Fbyte_code (bytestr=9727377, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:531
531               break;
(gdb) info args
bytestr = 9727377
vector = Variable "vector" is not available.
(gdb) up
#3  0x000000000054d59d in funcall_lambda (fun=29850740, nargs=1, 
    arg_vector=0x7fbfffb198)
    at [...]/emacs/src/eval.c:2974
2974          val = Fbyte_code (AREF (fun, COMPILED_BYTECODE),
(gdb) info args
fun = 29850740
nargs = 1
arg_vector = (long int *) 0x7fbfffb198
(gdb) up
#4  0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
2843            val = funcall_lambda (fun, numargs, args + 1);
(gdb) info args
nargs = Variable "nargs" is not available.
(gdb) up
#5  0x0000000000579cc9 in Fbyte_code (bytestr=9727377, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
686                 TOP = Ffuncall (op + 1, &TOP);
(gdb) info args
bytestr = 9727377
vector = Variable "vector" is not available.
(gdb) up
#6  0x000000000054d150 in Feval (form=Variable "form" is not available.
)
    at [...]/emacs/src/eval.c:2138
2138              val = (*XSUBR (fun)->function) (argvals[0], argvals[1],
(gdb) info args
form = Variable "form" is not available.
(gdb) up
#7  0x000000000054fcb8 in Fcondition_case (args=Variable "args" is not available.
)
    at [...]/emacs/src/eval.c:1332
1332      val = Feval (bodyform);
(gdb) info args
args = Variable "args" is not available.
(gdb) up
#8  0x000000000057925f in Fbyte_code (bytestr=29655265, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:864
864                 TOP = Fcondition_case (Fcons (TOP, v1));
(gdb) info args
bytestr = 29655265
vector = Variable "vector" is not available.
(gdb) up
#9  0x000000000054d59d in funcall_lambda (fun=29688788, nargs=3, 
    arg_vector=0x7fbfffb6f8)
    at [...]/emacs/src/eval.c:2974
2974          val = Fbyte_code (AREF (fun, COMPILED_BYTECODE),
(gdb) info args
nargs = Variable "nargs" is not available.
(gdb) up
#11 0x0000000000579cc9 in Fbyte_code (bytestr=11494737, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
686                 TOP = Ffuncall (op + 1, &TOP);
(gdb) info args
bytestr = 11494737
vector = Variable "vector" is not available.
(gdb) up
#12 0x000000000054d59d in funcall_lambda (fun=29857172, nargs=3, 
    arg_vector=0x7fbfffb8a8)
    at [...]/emacs/src/eval.c:2974
2974          val = Fbyte_code (AREF (fun, COMPILED_BYTECODE),
(gdb) info args
fun = 29857172
nargs = 3
arg_vector = (long int *) 0x7fbfffb8a8
(gdb) up
#13 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
2843            val = funcall_lambda (fun, numargs, args + 1);
(gdb) info args
nargs = Variable "nargs" is not available.
(gdb) up
#14 0x0000000000579cc9 in Fbyte_code (bytestr=25161265, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
686                 TOP = Ffuncall (op + 1, &TOP);
(gdb) info args
bytestr = 25161265
vector = Variable "vector" is not available.
(gdb) up
#15 0x000000000054d59d in funcall_lambda (fun=29855572, nargs=2, 
    arg_vector=0x7fbfffba78)
    at [...]/emacs/src/eval.c:2974
2974          val = Fbyte_code (AREF (fun, COMPILED_BYTECODE),
(gdb) info args
fun = 29855572
nargs = 2
arg_vector = (long int *) 0x7fbfffba78
(gdb) up
#16 0x000000000054daee in Ffuncall (nargs=Variable "nargs" is not available.
)
    at [...]/emacs/src/eval.c:2843
2843            val = funcall_lambda (fun, numargs, args + 1);
(gdb) info args
nargs = Variable "nargs" is not available.
(gdb) up
#17 0x0000000000579cc9 in Fbyte_code (bytestr=25161313, vector=Variable "vector" is not available.
)
    at [...]/emacs/src/bytecode.c:686
686                 TOP = Ffuncall (op + 1, &TOP);
--8<---------------cut here---------------end--------------->8---

Do you need more?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Variable "foo" is not available

[Daniel Jacobowitz]

On Mon, Apr 04, 2005 at 08:10:00AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Apr 2005 16:05:42 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> > 
> > > We are talking about function call arguments here, not just about any
> > > local variables.  Can you tell what compiler optimizations could cause
> > > what Reiner reported: that the first argument is available to GDB, but
> > > the second is not?
> > 
> > Very easily.  Suppose you have two incoming arguments in registers; GCC
> > will do this automatically for static functions even on i386, which
> > normally uses a stack convention.  The first is used after a function
> > call, so it is preserved by saving it to the stack.  The second is not
> > used after the function call, so the compiler has no reason to allocate
> > a save slot for it, and no reason to store it to memory before the
> > function call.
> 
> The functions present in Reiner's backtraces are not static, they are
> external, with the exception of funcall_lambda.  I don't have access
> to an x86_64 machine, but at least on an IA32 x86 architecture the
> code produced by GCC 3.4.3 for these function calls is quite
> straightforward (see one example below), and with GDB 6.3 I couldn't
> reproduce the "arg not available" message.

He gave us the missing clue in a later message - as Mark wrote, on
x86_64, the arguments are in registers.  This means the compiler must
explicitly save them.

> > With stack-based argument passing, GCC may be claiming an argument is
> > unavailable when the function's local copy is dead, when a copy still
> > exists on the stack somewhere.  I don't know if it will do that or not.
> > GDB can not assume that the argument is available in the incoming stack
> > slot, since it could be reused for other data.
> 
> What, if any, would be the expression of this in the machine code?

My x86 assembly is awful, so I tried to derive this from gcc output. 
The version of GCC I have installed will generate debug information
referring to the incoming argument slot, which I didn't expect it to
do.  So this is probably a non-issue.

> Also, I don't quite understand how can a stack slot of a function call
> argument be reused before the function returns.  Isn't that slot
> outside the function's frame?  Reusing it would be a violation of the
> ABI, right?

Actually, I don't think it would be.  This has been the subject of
considerable debate on the linux-kernel list in the past; GCC will 
sometimes modify these slots and the final consesnsus was that it was
within its rights to do so.

int foo();
int foo2 (int *);
int bar(int a)
{
  foo ();
  a += 3;
  foo2 (&a);
  return a + foo();
}

   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 08                sub    $0x8,%esp
   6:   e8 fc ff ff ff          call   7 <bar+0x7>
   b:   83 45 08 03             addl   $0x3,0x8(%ebp)
   f:   8d 45 08                lea    0x8(%ebp),%eax
  12:   89 04 24                mov    %eax,(%esp)
  15:   e8 fc ff ff ff          call   16 <bar+0x16>
  1a:   e8 fc ff ff ff          call   1b <bar+0x1b>
  1f:   8b 55 08                mov    0x8(%ebp),%edx
  22:   89 ec                   mov    %ebp,%esp
  24:   5d                      pop    %ebp
  25:   01 d0                   add    %edx,%eax
  27:   c3                      ret

See the instruction at 0xb?

GCC won't reuse the slot for an unrelated variable at present. 
However, in the future, it would be a valid optimization.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Variable "foo" is not available

[Eli Zaretskii]

> Date: Mon, 04 Apr 2005 08:57:47 +0100
> From: Daniel THOMPSON <daniel.thompson@st.com>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com,
>         Reiner.Steib@gmx.de
> 
> >>With stack-based argument passing, GCC may be claiming an argument is
> >>unavailable when the function's local copy is dead, when a copy still
> >>exists on the stack somewhere.  I don't know if it will do that or not.
> >>GDB can not assume that the argument is available in the incoming stack
> >>slot, since it could be reused for other data.
> > 
> > 
> > What, if any, would be the expression of this in the machine code?
> > 
> > Also, I don't quite understand how can a stack slot of a function call
> > argument be reused before the function returns.  Isn't that slot
> > outside the function's frame?  Reusing it would be a violation of the
> > ABI, right?
> 
> I doubt it.
> 
> The following C is perfectly valid.
> 
> void foo(int a, int b, int c, int d)
> {
> 	a = b + c;
> 	printf("a+d = %d\n", a, d);
> 	printf("b = %d\n", b);
> }
> 
> On modern architectures with a decent number of registers (including 
> IIRC the x86-64) a, b and c will be passed in registers rather than on 
> the stack.

Please note that, as should be clear from the citations above, my
question was about reusing a stack slot under a stack-based argument
passing scheme, not about passing arguments in registers.

Re: Variable "foo" is not available

[Eli Zaretskii]

> Date: Mon, 4 Apr 2005 09:37:44 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> 
> int foo();
> int foo2 (int *);
> int bar(int a)
> {
>   foo ();
>   a += 3;
>   foo2 (&a);
>   return a + foo();
> }
> 
>    0:   55                      push   %ebp
>    1:   89 e5                   mov    %esp,%ebp
>    3:   83 ec 08                sub    $0x8,%esp
>    6:   e8 fc ff ff ff          call   7 <bar+0x7>
>    b:   83 45 08 03             addl   $0x3,0x8(%ebp)
>    f:   8d 45 08                lea    0x8(%ebp),%eax
>   12:   89 04 24                mov    %eax,(%esp)
>   15:   e8 fc ff ff ff          call   16 <bar+0x16>
>   1a:   e8 fc ff ff ff          call   1b <bar+0x1b>
>   1f:   8b 55 08                mov    0x8(%ebp),%edx
>   22:   89 ec                   mov    %ebp,%esp
>   24:   5d                      pop    %ebp
>   25:   01 d0                   add    %edx,%eax
>   27:   c3                      ret
> 
> See the instruction at 0xb?

But this kind of code is only possible if the compiler examines all
the callers of `bar' and finds that none of them uses the value of
`bar's argument after `bar' returns.  So such code is probably only
possible in practice with static functions, right?  Or am I missing
something?

Also, is such optimizations really worth it?  I mean, the more
traditional code will mov the argument into a register and do the math
there; is adding to a memory location really faster than a mov and a
register-based add?

> GCC won't reuse the slot for an unrelated variable at present. 
> However, in the future, it would be a valid optimization.

Again, only if the compiler has enough information about the callers,
right?

Re: Variable "foo" is not available

[Daniel Jacobowitz]

On Mon, Apr 04, 2005 at 10:30:23PM +0300, Eli Zaretskii wrote:
> But this kind of code is only possible if the compiler examines all
> the callers of `bar' and finds that none of them uses the value of
> `bar's argument after `bar' returns.  So such code is probably only
> possible in practice with static functions, right?  Or am I missing
> something?

That would be true if the ABI labeled the stack slots as preserved
across the function call.  The consensus seems to be that it does not;
at the point of the function call they become part of the callee's
stack frame and it is free to modify them.

> Also, is such optimizations really worth it?  I mean, the more
> traditional code will mov the argument into a register and do the math
> there; is adding to a memory location really faster than a mov and a
> register-based add?

Yes, especially on decoding-limited processors.

Also, sibling calling does the same thing.  It reuses the stack slots
to pass arguments to a new function, and then jumps to the function.

> > GCC won't reuse the slot for an unrelated variable at present. 
> > However, in the future, it would be a valid optimization.
> 
> Again, only if the compiler has enough information about the callers,
> right?

No, as above.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Variable "foo" is not available

[Reiner Steib]

On Sat, Apr 02 2005, Daniel Jacobowitz wrote:

> On Sat, Apr 02, 2005 at 03:52:56PM +0200, Reiner Steib wrote:
>> Is it possible to detach from this session from gdb and re-attach
>> it to the snapshot gdb?
>
> Yes - it will run when you detach, though.  The commands are "detach"
> and "attach".  Who'd've guessed?

:-) I didn't have gdb installed on the machine on which I wrote this
message and I was offline.

As the machine with the gdb session had to be shut down because of a
scheduled shut down of the power supply, I can't provide further
information.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Variable "foo" is not available

[Eli Zaretskii]

> Date: Sat, 2 Apr 2005 09:26:40 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de
> 
> > 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?)
> 
> Only loclist_tracepoint_var_ref prints this message any more, assuming
> you are looking at a current version of the file.
> 
> 2005-02-28  Daniel Jacobowitz  <dan@codesourcery.com>
> 
>         * dwarf2loc.c (loclist_read_variable): Set optimized_out
>         instead of reporting an error.
>         * valprint.c (value_check_printable): New function.
>         (common_val_print): New function.  Use value_check_printable.
>         (value_print): Use value_check_printable.
>         * value.h (common_val_print): Add prototype.

So what message(s) or other effects would a user see with the current
CVS in situations such as the one Reiner described?  I'm asking
because I want to amend the manual.

TIA