Support 32-bit builds

[copumpkin]

When I try to run it in my 32-bit build environment, I get the following error:

arch/lkl/Makefile:14: *** Unrecognized platform: elf32-i386.  Stop.

Not sure if it's something weird about my environment (which is admittedly unusual), but I figured I'd avoid wasting time on it if it's not expected to work on 32-bit systems in the first place.

[Rondom]

I actually noticed this when testing my LFS-Pull-Request. :-)
I think it never really worked on Linux-i386. You can change arch/lkl/Makefile to get the kernel building, but it will fail during linking.

Take the following with a pinch of salt, I am by no means an expert on this, so anything of the following may be wrong, so please correct me in order for me to learn something ;-):
Reason for this seems to be our use of objcopy. It seems to discard some symbols (such as __x86.get_pc_thunk.bx) that are used internally for position independent code on i386. (They are used for storing the absolute addresses to jump to in a register). amd64 has relative addressing instructions, which is the reason why those symbols are not necessary there.

The only reference to a similar problem which I could find, was this bug report on the Debian and binutils bugtrackers (by the same person):

1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735564

I have yet to test, whether adding those symbols to the objcopy call would fix things. Then again, even if this makes it work, I am not really sure, whether it is the "right" approach, given that this is a highly implementation dependent thing.

[copumpkin]

Cool, thanks for the information. I actually don't use i386 for anything, but our automated build system tried to build it for i386 and failed, so I figured I'd ask. For now I'll just disable i386 builds for that package and call it a day 😄

You think it's worth me opening a separate ticket to support i386? I don't feel strongly about supporting it and it's probably more work for little gain.

[Rondom]

You think it's worth me opening a separate ticket to support i386? I don't feel strongly about supporting it and it's probably more work for little gain.

Didn't you just do that? I mean why do ask to open "a separate ticket", when you have, in fact, already opened one. So why not leave this ticket open?

I do not think it is a lot of work for someone who is familiar with those things and I do see some gain in fixing this. Despite claims to the contrary, i386 is not going disappear any time soon and there are other architectures that probably rely on similar helper-functions to implement position-independent code (which is why I am wary about hard-coding those symbols anywhere on our side).

(I am "only" a user, so let's hear what others think)

[copumpkin]

Fair enough 😄

[aostrouhhov]

Can this be fixed by modified linker script? We can tell it not to discard needed section.

[Rondom]

I think it can (at least that's what I remember from investigating it in March 2017). I think it's worth giving it a try.

[aostrouhhov]

Hmm, I do not understand the following thing.

Error messages I get on Ubuntu 16 (32-bit) looks like this:

'__x86.get_pc_thunk.bx' referenced in section '.text' of liblkl.a(lkl.o): defined in discarded section
'.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of liblkl.a(lkl.o)

But objdump -d liblkl.a contains the following lines:

Disassembly of section .text.__x86.get_pc_thunk.bx:

00000000 <__x86.get_pc_thunk.bx>:
0:   8b 1c 24                mov    (%esp),%eax
3:   c3                      ret

Why is it looking for .text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx] and not for .text.__x86.get_pc_thunk.bx section where __x86.get_pc_thunk.bx is defined? And why address is 00000000?

Also, I did not find .text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx] section in vmlinux from which liblkl.a is made. But .text.__x86.get_pc_thunk.bx and other sections are present and have the same description written above.

[aostrouhhov]

Why is it looking for .text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx] and not for .text.__x86.get_pc_thunk.bx section where __x86.get_pc_thunk.bx is defined?

I have some thoughts that actually .text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx] and .text.__x86.get_pc_thunk.bx may be equal.

[aostrouhhov]

Actually, the first thing I tried to fix problem with symbols was adding these symbols with -G option like this is done in pull request by luckyluke. But I found that this does not work. And here is the reason: after adding this fix you must execute make clean not just in linux/tools/lkl/ dir, but in linux/ dir too! On a hunch I expected another Build system behaviour but LKL is implemented as Linux port so may be this is right.