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 >>> >>>