i386

[tpimh]

This is WIP. Currently, lacking buildroot image (will add it when the kernel is able to boot), probably shouldn't be merged until ClangBuiltLinux/linux#3 is fixed.

UPD: rootfs added, booting fine with GNU ld, but not LLD (UPD2: fixed). After these issues are fixed, we can proceed with this PR:

• invalid output size for constraint '=q' in arch/x86/events/amd/core.c linux#194
• undefined reference to `__udivdi3' in vsyscall_gtod.c linux#578
• can't create dynamic relocation R_386_32 with LLD linux#579
• invalid output size for constraint '=q' in drivers/gpu/drm/i915/i915_query.c linux#781

[nickdesaulniers]

https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/211110274 shows that you're hitting what looks slightly similar to ClangBuiltLinux/linux#186.

ld: arch/x86/entry/vsyscall/vsyscall_gtod.o: in function `update_vsyscall':
vsyscall_gtod.c:(.text+0x262): undefined reference to `__udivdi3'

If the Makefile in arch/x86/entry/vsyscall/ does not have -Oz, then looks like we have another issue to deal with.

[nathanchance]

I was able to bisect the problematic commit as well: ClangBuiltLinux/linux#186 (comment)

[nickdesaulniers]

(I'll bet the sub expression tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift involves 64b numbers).

[tpimh]

Should ClangBuiltLinux/linux#186 be reopenned then?

[nathanchance]

A new issue should probably be opened.

[tpimh]

The patch to revert vgtod_ts commits is huge and most of it is unnecessary, but it works. Now there is also a problem with LLD, I will try to fix it later (or at least create an issue for it as I can't find one).

[nathanchance]

Tentatively seems good.

I assume those two patches are going to be upstreamed at some point? Given that we just got all of our LLVM 9 targets building patch free, it's a little sad to add some back.

[nathanchance]

It also looks like your percpu patch needs to be rebased?

[nickdesaulniers]

make sure to remove the WIP label when it's ready for code review

[tpimh]

The percpu patch is easy to fix so it builds, but this is not a proper fix, I'll check how similar issue was fixed with x86_64. The other patch should probably be rewritten as well. After these patches are upstreamed, i386 can be merged to master.

[tpimh]

Rebased with master and surprisingly it's broken. Builds fine, but doesn't boot. I will try to build 4.19 to see if it works.

[nickdesaulniers]

I recommend:

1. commit the buildroot changes separately first.
2. use qemu+gdb to see where we hang.

[nathanchance]

2. use qemu+gdb to see where we hang.

I was going to try this today but I cannot get the GDB scripts to load, am I doing something wrong?

% curl -LSs https://raw.githubusercontent.com/ClangBuiltLinux/continuous-integration/i386/patches/llvm-all/linux/i386/i386-percpu.patch | git apply -v
Checking patch arch/x86/include/asm/percpu.h...
Applied patch arch/x86/include/asm/percpu.h cleanly.

% echo "CONFIG_DEBUG_INFO=y\nCONFIG_GDB_SCRIPTS=y" >> arch/x86/configs/i386_defconfig

% make -j$(nproc) -s \
ARCH=i386 \
CC=clang \
O=out \
distclean defconfig bzImage

% qemu-system-i386 \
-m 512m \
-drive file=${HOME}/cbl/git/ci/images/i386/rootfs.ext4,format=raw,if=ide \
-append 'console=ttyS0 root=/dev/sda' \
-display none \
-serial mon:stdio \
-kernel ${HOME}/src/linux/out/arch/i386/boot/bzImage \
-s \
-S

% echo "add-auto-load-safe-path ${PWD}/scripts/gdb/vmlinux-gdb.py" >> ~/.gdbinit

% gdb out/vmlinux
GNU gdb (GDB) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from out/vmlinux...
(gdb) target remote :1234
Remote debugging using :1234
0x0000fff0 in ?? ()
(gdb) lx-version
Undefined command: "lx-version".  Try "help".
(gdb) apropos lx
(gdb) 

[tpimh]

Exactly the same problem here. I was trying to get it working for a while, tried everything I could think of, but no luck, apropos lx always showed nothing. Created a couple forum threads about my problem, but got zero responses. Really started to think that this is just my problem, and I am doing something wrong. If it's the case, at least I'm not alone now.

The only useful piece information I got with gdb is that the kernel panics with "Attempted to kill the idle task!"

[tpimh]

@nickdesaulniers which version of fix for invalid output size for constraint '=q' do you think is better: ClangBuiltLinux/linux#194 (comment)?

[nickdesaulniers]

which version of fix for invalid output size for constraint '=q' do you think is better: ClangBuiltLinux/linux#194 (comment)?

https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints says for q:

Any register accessible as rl. In 32-bit mode, a, b, c, and d; in 64-bit mode, any integer register.

so for inputs I prefer @dwmw2's approach of casting to (unsigned char) which is truncation. I don't understand why there's a cast to (unsigned long) though, which will zero extend. I need to look more at the sources (the diff doesn't have all the info I need to make a more informed decision). We already know the size, so I think we could just cast to the unsigned integral type of the equivalent byte size.

For outputs, I also prefer @dwmw2's approach of using a temporary unsigned char as output, though I again don't think the cast to (unsigned long) is necessary.

Though @arndb is cleaner, and the b suffix on the assembler mnemonics should use the rl register aliases regardless of the q vs r constraint. It would be good to check whether q changes the disassembly for gcc. I suspect it won't but I could be wrong.

Either way, we could start a thread with @arndb , @dwmw2, and Linus, since Linus emailed me about this case recently, and understands the point @dwmw2 makes in his commit message.

[tpimh]

Building with no LLD: Build #1397. All should be fine.

Should I rename the ARCH from i386 to x86 to match the new images in boot-utils?

[nickdesaulniers]

yes please. Originally, I had the images as i386, but the kernel image gets produced in arch/x86/boot/, so it was simpler to just use x86 everywhere.

[nickdesaulniers]

Boot failures on -next look like:

Could not access KVM kernel module: No such file or directory
qemu-system-i386: failed to initialize KVM: No such file or directory

hmmm

Also, patches aren't applying cleanly to mainline.

[nathanchance]

Boot failures on -next look like:

Could not access KVM kernel module: No such file or directory

qemu-system-i386: failed to initialize KVM: No such file or directory

hmmm

Fixed by ClangBuiltLinux/boot-utils#12.

[nickdesaulniers]

I've rekicked the tests.

[nathanchance]

Aside from the one comment, LGTM.

[nickdesaulniers]

Nice work @tpimh ! Thanks

[nickdesaulniers]

I plan to land https://reviews.llvm.org/D79804 which is an improvement to Clang, but will make the patches we're carrying no longer work.