[llvmlinux] Linux-v3.10 is bootable here

PaX Team pageexec at gmail.com
Fri Jul 12 16:12:52 UTC 2013


On 12 Jul 2013 at 16:56, Sedat Dilek wrote:

in addition to what Behan said:

> But you say building for -march=i386 produces different assembler-code, right?

sort of, while -march enables (and restricts) the use of insns specific to a
given CPU model so that the generated code is guaranteed to work on such a CPU,
it's only enforced for compiler generated machine code as -march doesn't seem to
be passed down to the assembler when gcc is invoked for assembly sources (whether
that's a feature or bug itself i don't know).

the problem you'll run into with llvm and integrated-as is that this property
(CPU model selection) will also be enforced on both inline asm in C and assembly
source files. and it is this latter where linux uses insns that were not present
in the i386 days and thus -march=i386 triggers errors.

now this is not an actual runtime problem because such CPU model specific code
is conditionally executed (only after the CPU model and insn set support has
been determined) but integrated-as doesn't know about this so i went for the
admittedly cheapest but less than ideal 'fix' to allow successful assembly (like
probably most of us, i've been testing on recent enough CPUs that selecting 586
wouldn't be a problem).

the better approach for such assembly sources would be to add CPU model selection
directives (.arch iirc) around these special insns, so patches are welcome ;).

> Fact is, the Linux-kernel dropped i386-arch support with v3.10.

[i think it was more like 3.8]

> So, we should use -march=i586 for the 16bit-code part in x86-boot and
> x86-realmode?

like i said, this march setting is not relevant for assembly sources and in
fact it could be harmful for C files since the compiler is now allowed to
generate insns that only 586+ CPUs understand. so if anything, this should
be fixed properly with CPU model directives as suggested above.

> What is the minimum -march?
> As llvmlinux supports i586 (x86 32-bit), that above march-line makes
> sense to me.

this i don't know, mainline linux itself (which is the target of llvmlinux)
definitely supports 486 (well, at least conceptually, i don't know who runs
on such a CPU these days, perhaps some embedded systems do) so i'd say you
can't go up to 586 and my workaround will have to be redone properly for
upstream inclusion.

> BTW, why do you have "-mno-sse" in x86-boot but not in x86-realmode Makefile?

it's an oversight i think, no kernel code should be compiled without -mno-sse.



More information about the LLVMLinux mailing list