From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Mon, 28 Nov 2016 21:33:35 +0200 Message-ID: <834m2rz9f4.fsf@gnu.org> References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <805F5A19-BFAF-4CA4-AAD6-497C6D554830@raeburn.org> <6e5c928f-8130-08a6-d72d-1b64cc022846@cs.ucla.edu> <1CB11DFF-E6C2-4A1B-BE7E-8877DC38DB0A@raeburn.org> <83inr7zjjf.fsf@gnu.org> <83bmwzzet5.fsf@gnu.org> <781CA5B8-3DEA-43C8-B9C3-AC4AAEA21950@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1480361647 26017 195.159.176.226 (28 Nov 2016 19:34:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 19:34:07 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 20:34:02 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cBRgf-0006AT-Vv for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 20:34:02 +0100 Original-Received: from localhost ([::1]:60757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBRgj-000310-NX for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 14:34:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBRgW-0002ze-EY for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:33:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBRgT-0001r1-75 for emacs-devel@gnu.org; Mon, 28 Nov 2016 14:33:52 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBRgT-0001qw-3f; Mon, 28 Nov 2016 14:33:49 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3745 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cBRgQ-0003uD-LF; Mon, 28 Nov 2016 14:33:48 -0500 In-reply-to: <781CA5B8-3DEA-43C8-B9C3-AC4AAEA21950@raeburn.org> (message from Ken Raeburn on Mon, 28 Nov 2016 14:09:44 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209675 Archived-At: > From: Ken Raeburn > Date: Mon, 28 Nov 2016 14:09:44 -0500 > Cc: Stefan Monnier , > 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?).