After adding a very long busy loop to gnumach, testing It in my T60, exec
boots without problems.
So I can confirm that exec hang has disappeared.

El jue., 8 oct. 2020 a las 19:26, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:

> After testing "upstream" and Debian's GNU Mach over my Thinkpad machines
> (T60, R60e and T410), the exec problem seems to have disappeared.
> To be sure, I go to repeat the test adding some long code to delay the
> booting.
>
>
>
> El jue., 8 oct. 2020 a las 13:11, Almudena Garcia (<
> liberamenso10...@gmail.com>) escribió:
>
>> I can test It over real hardware, in which usually we can see more
>> problems than in a virtual scenery. When I finish the test, I will report
>> the results here.
>> In Qemu, the boot looks fine, and the exec problems seem to have
>> disappeared. I tested It using gnumach in SMP mode (--enable-cpus=2).
>>
>> El jue., 8 oct. 2020 a las 0:17, Samuel Thibault (<
>> samuel.thiba...@gnu.org>) escribió:
>>
>>> Hello,
>>>
>>> I might have found the trigger for the exec hang at boot. The symptoms
>>> were that very early during the program loading by ld.so, it would
>>> overflow its stack with 0x40, apparently because there were odd things
>>> happening with the GOT. One odd thing was that ld.so was getting loaded
>>> at 0x0. That's because it is a PIE. Issues that might come up are that
>>> pointer 0x0 could then actually be a should-be-valid pointer...  I
>>> modified gnumach to load PIE binaries at 0x8000000, like our exec server
>>> does, and couldn't reproduce the exec hang at boot. This is now in
>>> debian as gnumach version 2:1.8+git20201007-1.
>>>
>>> Samuel
>>>
>>>

Reply via email to