[Ecls-list] Bug in code detecting stack growth direction

[Juan Jose Garcia-Ripoll]

On Fri, Feb 3, 2012 at 5:24 PM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

>
> This confusese two things: (1) the existence of a stack; (2) the
> direction of growth.
> The test for (2) is invoking an undefined behaviour.  Therefore, the
> outcome of
> that test does not say anything about the collector's assumption that
> there is
> a stack (1) and a defined direction of growth.


Actually, both things are related. The collector uses the same logic. It
assumes that there is a stack (1) and it assumes that when GC is invoked,
the address that it currently has (a) can be retrieved by looking at the
closest atomic variable and (b) it can be compared with a similarly
retrieved address found at the thread's entry point

This is what I have always found in all the versions I have reviewed,
except for some platforms that offer an API to retrieve that information
from different threads. It is also the reason why the GC has some funny
API, intercepting calls to pthread_create() and providing functions to
"import" a current thread...

So yes, I know that the assumption that automatic variables and call frames
are sorted is based on a de-facto standard and could be broken, but right
now there is no other way which does not involve nonportable assembly code
and changing the GC library as well.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120203/67201ea4/attachment.html>