Hello,
I thought I'd try and get L4Re and the UX variant of Fiasco.OC working again. Various errors with the actual compiler - not typical compilation errors - have previously occurred, but system updates come along every so often and I saw that new revisions of L4Re/Fiasco.OC have also arrived fairly recently.
Unfortunately, the L4Re build fails with complaints about the linking process. Here is the verbose build output at the point of failure:
[fb-drv] ==> Linking fb-drv LD_PRELOAD=libgendep.so LD_LIBRARY_PATH=:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep/32:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep GENDEP_TARGET=fb-drv GENDEP_BINARY=ld GENDEP_BINARY_ALT1=ld /home/paulb/L4/UX/src/l4/tool/bin/l4-bender -t ld - Dl4obj=/home/paulb/L4/UX/src/l4/mybuild -Dl4dir=/home/paulb/L4/UX/src/l4 - Dgcclibdir="/usr/lib/gcc/i686-linux-gnu/7/ /usr/lib/gcc/i686-linux- gnu/7/../../../../i686-linux-gnu/lib/i686-linux-gnu/7/ /usr/lib/gcc/i686- linux-gnu/7/../../../../i686-linux-gnu/lib/i386-linux-gnu/ /usr/lib/gcc/i686- linux-gnu/7/../../../../i686-linux-gnu/lib/../lib/ /usr/lib/gcc/i686-linux- gnu/7/../../../i686-linux-gnu/7/ /usr/lib/gcc/i686-linux-gnu/7/../../../i386- linux-gnu/ /usr/lib/gcc/i686-linux-gnu/7/../../../../lib/ /lib/i686-linux- gnu/7/ /lib/i386-linux-gnu/ /lib/../lib/ /usr/lib/i686-linux-gnu/7/ /usr/lib/i386-linux-gnu/ /usr/lib/../lib/ /usr/lib/gcc/i686-linux- gnu/7/../../../../i686-linux-gnu/lib/ /usr/lib/gcc/i686-linux-gnu/7/../../../ /lib/ /usr/lib/" -Dl4system=x86_gen -Dl4api=l4f -Dlinker="ld -m elf_i386" -- spec=/home/paulb/L4/UX/src/l4/mk/bid-bender.spec -- -o fb-drv -MD -MF ./.fb- drv.pcs.d -PClibc_support_misc -PClibio-vbus -PCx86emu_int10 -PCx86emu_int10 - PCstdlibs -static -gc-sections -Ttext-segment=0x01000000 --defsym __L4_KIP_ADDR__=0xaffff000 --defsym __L4_STACK_ADDR__=0xb0000000 -L /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen/l4f -L /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen -L /home/paulb/L4/UX/src/l4/mybuild/lib --warn-common -Ttext-segment=0x01000000 main.o dummy.o splash.o vesa.o ld: section `.note.gnu.property' assigned to non-existent phdr `interp' ld: section `.rel.dyn' assigned to non-existent phdr `interp'
I know that the ldscripts have been changed, but I struggle to see how the above relates to them or whether they are even involved in this particular outcome. Might there be something obviously wrong somewhere in the recent changes?
Paul
Hi Paul,
On Fri Aug 03, 2018 at 00:26:45 +0200, Paul Boddie wrote:
I thought I'd try and get L4Re and the UX variant of Fiasco.OC working again. Various errors with the actual compiler - not typical compilation errors - have previously occurred, but system updates come along every so often and I saw that new revisions of L4Re/Fiasco.OC have also arrived fairly recently.
Unfortunately, the L4Re build fails with complaints about the linking process. Here is the verbose build output at the point of failure:
[fb-drv] ==> Linking fb-drv LD_PRELOAD=libgendep.so LD_LIBRARY_PATH=:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep/32:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep GENDEP_TARGET=fb-drv GENDEP_BINARY=ld GENDEP_BINARY_ALT1=ld /home/paulb/L4/UX/src/l4/tool/bin/l4-bender -t ld - Dl4obj=/home/paulb/L4/UX/src/l4/mybuild -Dl4dir=/home/paulb/L4/UX/src/l4 - Dgcclibdir="/usr/lib/gcc/i686-linux-gnu/7/ /usr/lib/gcc/i686-linux- gnu/7/../../../../i686-linux-gnu/lib/i686-linux-gnu/7/ /usr/lib/gcc/i686- linux-gnu/7/../../../../i686-linux-gnu/lib/i386-linux-gnu/ /usr/lib/gcc/i686- linux-gnu/7/../../../../i686-linux-gnu/lib/../lib/ /usr/lib/gcc/i686-linux- gnu/7/../../../i686-linux-gnu/7/ /usr/lib/gcc/i686-linux-gnu/7/../../../i386- linux-gnu/ /usr/lib/gcc/i686-linux-gnu/7/../../../../lib/ /lib/i686-linux- gnu/7/ /lib/i386-linux-gnu/ /lib/../lib/ /usr/lib/i686-linux-gnu/7/ /usr/lib/i386-linux-gnu/ /usr/lib/../lib/ /usr/lib/gcc/i686-linux- gnu/7/../../../../i686-linux-gnu/lib/ /usr/lib/gcc/i686-linux-gnu/7/../../../ /lib/ /usr/lib/" -Dl4system=x86_gen -Dl4api=l4f -Dlinker="ld -m elf_i386" -- spec=/home/paulb/L4/UX/src/l4/mk/bid-bender.spec -- -o fb-drv -MD -MF ./.fb- drv.pcs.d -PClibc_support_misc -PClibio-vbus -PCx86emu_int10 -PCx86emu_int10 - PCstdlibs -static -gc-sections -Ttext-segment=0x01000000 --defsym __L4_KIP_ADDR__=0xaffff000 --defsym __L4_STACK_ADDR__=0xb0000000 -L /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen/l4f -L /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen -L /home/paulb/L4/UX/src/l4/mybuild/lib --warn-common -Ttext-segment=0x01000000 main.o dummy.o splash.o vesa.o ld: section `.note.gnu.property' assigned to non-existent phdr `interp' ld: section `.rel.dyn' assigned to non-existent phdr `interp'
I know that the ldscripts have been changed, but I struggle to see how the above relates to them or whether they are even involved in this particular outcome. Might there be something obviously wrong somewhere in the recent changes?
I also saw this, I currently believe this is due to the latest binutils (2.31). Are you running this one?
Adam
On Friday 3. August 2018 15.36.50 Adam Lackorzynski wrote:
On Fri Aug 03, 2018 at 00:26:45 +0200, Paul Boddie wrote:
I know that the ldscripts have been changed, but I struggle to see how the above relates to them or whether they are even involved in this particular outcome. Might there be something obviously wrong somewhere in the recent changes?
I also saw this, I currently believe this is due to the latest binutils (2.31). Are you running this one?
Yes, that's the one:
binutils 2.31.1-2 on i386
I guess I could use a more stable distribution version to see if this resolves the problem. I'll give it a try and report back.
Thanks for following up!
Paul
On Friday 3. August 2018 15.49.56 Paul Boddie wrote:
On Friday 3. August 2018 15.36.50 Adam Lackorzynski wrote:
On Fri Aug 03, 2018 at 00:26:45 +0200, Paul Boddie wrote:
I know that the ldscripts have been changed, but I struggle to see how the above relates to them or whether they are even involved in this particular outcome. Might there be something obviously wrong somewhere in the recent changes?
I also saw this, I currently believe this is due to the latest binutils (2.31). Are you running this one?
Yes, that's the one:
binutils 2.31.1-2 on i386
I guess I could use a more stable distribution version to see if this resolves the problem. I'll give it a try and report back.
A quick update, then. Quickly testing with revision 76 on Debian stable with binutils 2.28-5, I was able to launch the framebuffer-example in UX.
However, updating to revision 80 under the same configuration, I get the following:
fbdrv | Trying execution of ``set VBE mode'' using x86emu fbdrv | L4Re[rm]: unhandled read page fault at 0xfd0 pc=0x1005155 fbdrv | L4Re: rom/fb-drv: Unhandled exception: PC=0x1005155 PFA=fd0 LdrFlgs=0
Comparing earlier output with the successful revision, I see that the following is missing after the BOOTFS output:
VESAFB: [C:11c010][C:11b000] @c0000000 (size=400000)
Also, at the very beginning, the following is missing:
Starting Framebuffer: 800x600@32
Since the hello example works fine, I'll try and track down which part of the framebuffer configuration went missing.
Paul
P.S. Binutils has been playing up with other software for me today, but sadly a change of version is not the same apparently-easy fix for that other software.
On Saturday 4. August 2018 01.25.00 Paul Boddie wrote:
A quick update, then. Quickly testing with revision 76 on Debian stable with binutils 2.28-5, I was able to launch the framebuffer-example in UX.
However, updating to revision 80 under the same configuration, I get the following:
fbdrv | Trying execution of ``set VBE mode'' using x86emu fbdrv | L4Re[rm]: unhandled read page fault at 0xfd0 pc=0x1005155 fbdrv | L4Re: rom/fb-drv: Unhandled exception: PC=0x1005155 PFA=fd0 LdrFlgs=0
Comparing earlier output with the successful revision, I see that the following is missing after the BOOTFS output:
VESAFB: [C:11c010][C:11b000] @c0000000 (size=400000)
Also, at the very beginning, the following is missing:
Starting Framebuffer: 800x600@32
Since the hello example works fine, I'll try and track down which part of the framebuffer configuration went missing.
This is obvious after a night's sleep, of course. The Fiasco configuration needs the framebuffer to be enabled, and having performed a completely separate build, I hadn't descended into the options to enable it once again:
"Kernel options" -> "Graphical console (requires SDL library!)"
Recompiling Fiasco and then re-running the framebuffer-example...
make O=mybuild ux E=framebuffer-example
...worked once more. So, to summarise, binutils 2.28 is fine, 2.31 possibly isn't, and UX works fine on i386 within these constraints.
Paul
On Fri Aug 03, 2018 at 15:49:56 +0200, Paul Boddie wrote:
On Friday 3. August 2018 15.36.50 Adam Lackorzynski wrote:
On Fri Aug 03, 2018 at 00:26:45 +0200, Paul Boddie wrote:
I know that the ldscripts have been changed, but I struggle to see how the above relates to them or whether they are even involved in this particular outcome. Might there be something obviously wrong somewhere in the recent changes?
I also saw this, I currently believe this is due to the latest binutils (2.31). Are you running this one?
Yes, that's the one:
binutils 2.31.1-2 on i386
I guess I could use a more stable distribution version to see if this resolves the problem. I'll give it a try and report back.
Thanks for following up!
Issue has been fixed by now. Was a mistake in the linkerscript where earlier ld versions did not complain.
Adam
On Tuesday 7. August 2018 23.00.25 Adam Lackorzynski wrote:
Issue has been fixed by now. Was a mistake in the linkerscript where earlier ld versions did not complain.
Thanks once again for following up! This is possibly useful to know for other reasons, too, of course. I'll try and confirm that it works again for me tomorrow.
Paul
On Tuesday 7. August 2018 23.47.44 Paul Boddie wrote:
On Tuesday 7. August 2018 23.00.25 Adam Lackorzynski wrote:
Issue has been fixed by now. Was a mistake in the linkerscript where earlier ld versions did not complain.
Thanks once again for following up! This is possibly useful to know for other reasons, too, of course. I'll try and confirm that it works again for me tomorrow.
Well, the linker problems went away, but I haven't managed to get the graphical console to appear under revision 81 with binutils 2.31.1-2.
Indeed, I seem to experience the ux_con processes being started and persisting even after the UX system has halted. Under certain conditions, fiasco processes persist as well, using up CPU cycles.
I'll try and figure out what might be happening, but if there are any hints about what to look for, I'm sure they will be very useful. Nevertheless, just getting UX to work again has been helpful for the exploration of certain things within L4Re.
Paul
l4-hackers@os.inf.tu-dresden.de