Closed steveklabnik closed 6 years ago
steveklabnik
commented
7 years ago So, I've figured it out.
[bin]
name = "intermezzos"
test = falseWill 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.
steveklabnik
commented
7 years ago Idea: move the lib crate out into its own path dependency. This would be less than ideal, but would at least let things work.
steveklabnik
commented
7 years ago alternatives:
WilsonGiese
commented
7 years ago 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
steveklabnik
commented
7 years ago I've been playing with it, it now compiles, but doesn't work.
https://github.com/intermezzOS/kernel/commit/e28254e57ce3b2f1451c0a9e6b50a4e7f3aca057
steveklabnik
commented
7 years ago (I'm pushing more commits to that branch as I try things)
steveklabnik
commented
7 years ago I can confirm, at least, that when doing so, 'cargo test' does actually work, so that's nice.
WilsonGiese
commented
7 years ago 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.
steveklabnik
commented
7 years ago 
(happens with .globl as well)
steveklabnik
commented
7 years ago WilsonGiese
commented
7 years ago 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.
WilsonGiese
commented
7 years ago 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.
WilsonGiese
commented
7 years ago 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
steveklabnik
commented
7 years ago Man, all of this is like magic to me!
Right! Still learning a lot, though.
jtgeibel
commented
7 years ago 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.