[Vm-dev] Alien on Spur and "el capitan"?

[Eliot Miranda]

On Tue, Oct 20, 2015 at 2:54 PM, Esteban Lorenzano <estebanlm at gmail.com>
wrote:

>
>
> On 20 Oct 2015, at 23:50, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>
>
> On 20 Oct 2015, at 23:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Esteban,
>
> On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>
>>
>>
>> On 20 Oct 2015, at 22:59, John McIntosh <johnmci at smalltalkconsulting.com>
>> wrote:
>>
>> Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH
>> unsigned and signed integers? That to me rings alarm bells, so do you
>> need maybeInlinePositive32BitIntegerForSignedInteger
>> or maybeInlinePositive32BitIntegerForUnSignedInteger  or always cast the
>> incoming value to an unsigned integer, or is it signed? If so are you sure
>> you understand the math involved and the possible input values?
>>
>>
>> I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot
>> who is doing it :)
>> But yes, I thought that first, then I followed the logic and figured out
>> the intent was kept just changing the input type… but I might be wrong…
>> Eliot should know better :)
>>
>
> what's the context?
>
>
> I spotted the problem when calling
>
> sendInvokeCallbackContext:
>
> in concrete, when doing this:
>
> self push: (self positiveMachineIntegerFor: vmCallbackContext
> asUnsignedInteger).
>
> positiveMachineIntegerFor: always inlines the callback context (answering
> then a random position in memory).
>
> and after analysis, I found that the casting of oop with “unsigned long”
> makes that the two comparisons in:
>
>
> if ((integerValue >= 0)
>  && ((integerValue ^ (integerValue << 1)) >= 0)) {
> object3 = ((integerValue << 1) | 1);
> goto l12;
> }
>
> always evaluates to true, no matter the value it receives.
>
>
> btw the compiler warnings about this all the time, not just on
> sendInvokeCallbackContext:… that’s why I wonder how this is possible to
> work before :(
>

Maybe it was only working before because of the address range in which
callbackContext occurred.  Maybe in el capital the stack is in a different
place in memory and now it breaks things.

> Esteban
>
>
>> Esteban
>>
>> On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm at gmail.com>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> Does anyone tested Alien on Spur and "El capitan"? specifically
>>> callbacks?
>>> For me, a completely broken :(
>>>
>>> 1) this structure (in maybeInlinePositive32BitIntegerFor: and others):
>>>
>>> (integerValue >= 0
>>>  and: [objectMemory isIntegerValue: integerValue]) ifTrue:
>>> [^objectMemory integerObjectOf: integerValue].
>>>
>>> Does not works if “integer value” is an unsigned long, because compiler
>>> assumes it will always be true, then remove the if, then answers a wrong
>>> value.
>>>
>>> 2) assertCStackWellAligned always fail. No idea why because if does not
>>> says anything, just jmp back to the regular flow.
>>>
>>> 3) finally, ceCaptureCStackPointers also fails… this can be because (2)
>>> or because other reasons (it also jmps back so no clue) (method
>>> generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped
>>> to work).
>>>
>>> I guess solution of (1) is easy: argument number just has to be a sqLong
>>> instead an unsigned long.
>>>
>>> But for 2 and 3 I have no idea where to start.
>>>
>>> Does anyone has an idea?
>>>
>>> Esteban
>>>
>>>
>>>
>>
>>
>> --
>>
>> ===========================================================================
>> John M. McIntosh. Corporate Smalltalk Consulting Ltd
>> https://www.linkedin.com/in/smalltalk
>>
>> ===========================================================================
>>
>> _,,,^..^,,,_
> best, Eliot
>
> _,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151020/7e860a82/attachment-0001.htm