Closed steveklabnik closed 6 years ago
So, I've figured it out.
[bin]
name = "intermezzos"
test = false
Will ensure that the main
doesn't get tested, and then, removing the build.rs
works to test the library crate.
So, the key question is: can we not do the build.rs
stuff in test? I'm not sure.
Idea: move the lib crate out into its own path
dependency. This would be less than ideal, but would at least let things work.
alternatives:
port nasm -> intel syntax, then we can assemble with gcc, which will produce PIC-code
Assembling with GCC sounds the nicest, but I'm not sure how much effort is required to port the code; not too familiar with the exact differences between nasm and intel syntax
I've been playing with it, it now compiles, but doesn't work.
https://github.com/intermezzOS/kernel/commit/e28254e57ce3b2f1451c0a9e6b50a4e7f3aca057
(I'm pushing more commits to that branch as I try things)
I can confirm, at least, that when doing so, 'cargo test' does actually work, so that's nice.
Hmm... What exactly does "doesn't work" mean? Have you stepped with GDB?
The only thing that sticks out to me from a quick glance: should .global start
be .globl start
?
Kind of assuming it wouldn't compile without the directive, but I have no idea and can't test it atm.
(happens with .globl as well)
I ran readelf --header target/isofiles/boot/intermezzos
for both the working & broken versions:
Working: Entry point address: 0x1018c4
!Working: Entry point address: 0x0
Not really sure if this is at all helpful, obviously the entry point is wrong, but maybe this info could prove useful to determine the issue (but I've got nothing). There's also many other differences in the header than just the entry point.
Added *(.boot)
to the .boot section of the linker file, and now the ELF file looks more like the one produced when using nasm, but it still doesn't work. It is able to find the entry point, but ends up in some kind of crash loop in QEMU.
.boot :
{
header_start = .;
...
header_end = .;
*(.boot)
}
On the #rust-osdev IRC, it was suggested that
.section .boot, "ax"
was the problem. And that does seem to be the case; now I get the triple fault you're seeing.
Interesting; this modification produces a different ELF than the linker change.
Man, all of this is like magic to me! I spent a bit of time reading both GAS and linker syntax docs and I don't think I saw anything regarding .section flags. Now that I know they exist I found one document describing them
Man, all of this is like magic to me!
Right! Still learning a lot, though.
I ran into this same error today at rust-belt-rust conference. Interestingly, I see this error when building, not just when running tests. I'm currently on Ubuntu yakkety with the following versions:
$ rustc -vV
rustc 1.14.0-nightly (3caf63cc0 2016-10-24)
binary: rustc
commit-hash: 3caf63cc00f5cec580954bdb117f4fa756cc757d
commit-date: 2016-10-24
host: x86_64-unknown-linux-gnu
release: 1.14.0-nightly
LLVM version: 3.9
$ nasm -v
NASM version 2.12.01
$ ld -v
GNU ld (GNU Binutils for Ubuntu) 2.27
$ cc -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)
https://users.rust-lang.org/t/utest-unit-test-ing-for-microcontrollers-and-other-no-std-systems/9695
might be an answer to this issue
We don't currently have any unit tests here, so it's not a problem, but we should figure this out and fix it.
Someone on IRC told me that the PIC stuff would be fixed if we used gcc to assemble rather than nasm. Unsure though.