all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ken Raeburn <raeburn@raeburn.org>
Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Conservative GC isn't safe
Date: Mon, 28 Nov 2016 21:33:35 +0200	[thread overview]
Message-ID: <834m2rz9f4.fsf@gnu.org> (raw)
In-Reply-To: <781CA5B8-3DEA-43C8-B9C3-AC4AAEA21950@raeburn.org> (message from Ken Raeburn on Mon, 28 Nov 2016 14:09:44 -0500)

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Mon, 28 Nov 2016 14:09:44 -0500
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  eggert@cs.ucla.edu,
>  emacs-devel@gnu.org
> 
> >> But after computing "aref_addr (string, ifrom)", it may very well be
> >> that `string` is dead and the compiler may then decide not to write
> >> it into the stack.
> > 
> > It will still be there in the caller.
> 
> Not if Fsubstring (or whatever function) is applied directly to the return value from some other call.

No, it still will be there.

You need to keep in mind how these variables get to Lisp, and for what
purposes.  Our code is written for certain purposes, and that mandates
how data flows in the code.  If you go high enough up the stack, you
will find every Lisp object value that matters at some level.

> As Björn described, the caller may not keep it around at all, just shift it from register to register, and the callee can scribble over those registers.

The number of registers is finite, even in the x86_64 architectures.
The compiler cannot keep storing values in registers, because it needs
to leave enough of them available for the next level of function
invocation, about which it knows nothing before that function is
called.  Go deep enough, and values will be pushed on the stack
because the compiler needs to free a register.

> Even if there’s an automatic variable assigned the value, if it’s not used later, the compiler may optimize it away; I’ve lost track of how many times GDB has indicated to me that it recognizes a variable name but at the current point in the code it’s been optimized out so GDB can’t show it to me.

The fact that GDB cannot tell you the value, and instead throws the
"optimized out" thing at you, is just a sign that GCC didn't leave
behind enough information for GDB to get its act together, and/or that
GDB has bugs, and/or that DWARF is not expressive enough to cover some
ingenious optimization technique.  It doesn't necessarily tell
anything about where the value really is.  If anything, it means the
value is not in a register, i.e. likely on the stack (where else?).



  reply	other threads:[~2016-11-28 19:33 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-26  8:11 Conservative GC isn't safe Daniel Colascione
2016-11-26  8:30 ` Paul Eggert
2016-11-26  8:33   ` Daniel Colascione
2016-11-26  9:01     ` Eli Zaretskii
2016-11-26  9:04       ` Daniel Colascione
2016-11-26  9:24         ` Eli Zaretskii
2016-11-26 15:05         ` Stefan Monnier
2016-11-26 15:21           ` Camm Maguire
2016-11-28 17:51           ` Daniel Colascione
2016-11-28 18:00             ` Eli Zaretskii
2016-11-28 18:03               ` Daniel Colascione
2016-11-28 18:50                 ` Eli Zaretskii
2016-11-28 18:03             ` Stefan Monnier
2016-11-28 19:18               ` Daniel Colascione
2016-11-28 19:33                 ` Stefan Monnier
2016-11-28 19:37                 ` Eli Zaretskii
2016-11-28 19:40                   ` Daniel Colascione
2016-11-28 20:03                     ` Eli Zaretskii
2016-11-28 20:09                       ` Daniel Colascione
2016-11-28 19:26               ` Andreas Schwab
2016-11-28 19:34                 ` Stefan Monnier
2016-11-26 15:03   ` Stefan Monnier
2016-11-26 15:12     ` Eli Zaretskii
2016-11-26 16:29       ` Stefan Monnier
2016-11-26 16:42         ` Eli Zaretskii
2016-11-26 18:43           ` Stefan Monnier
2016-11-27  6:17     ` Ken Raeburn
2016-11-27 15:39       ` Eli Zaretskii
2016-11-28  9:50         ` Ken Raeburn
2016-11-28 15:55           ` Eli Zaretskii
2016-11-27 16:15       ` Paul Eggert
2016-11-28  9:36         ` Ken Raeburn
2016-11-28 15:55           ` Eli Zaretskii
2016-11-28 16:15             ` Stefan Monnier
2016-11-28 17:37               ` Eli Zaretskii
2016-11-28 17:49                 ` Stefan Monnier
2016-11-28 17:57                   ` Eli Zaretskii
2016-11-28 18:05                     ` Stefan Monnier
2016-11-28 19:09                 ` Ken Raeburn
2016-11-28 19:33                   ` Eli Zaretskii [this message]
2016-11-29  8:49                     ` Ken Raeburn
2016-11-28 17:03             ` Björn Lindqvist
2016-11-28 16:13           ` Paul Eggert
2016-11-27 16:52       ` Stefan Monnier
2016-11-26 19:08 ` Pip Cet
2016-11-27  0:24   ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834m2rz9f4.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=raeburn@raeburn.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.