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