search

hackndev / zinc

The bare metal stack for rust
zinc.rs
Apache License 2.0
1k stars 100 forks source link

Failing to build example. #336

Closed rvlander closed 8 years ago

rvlander commented 9 years ago

I have tried different way to build examples but without success.

The README page seems to be outdated. I tried to directly cargo build in an example dir, but there is a compilation error when compiling core.

I tried to look to travis log to find a way: I have have another compilation error.

posborne commented 9 years ago

@rvlander What version of rust? Also, can you post the compilation error you are getting?

rvlander commented 9 years ago

@posborne, what method should I use? README based? Travis base? or cargo build in example directory?

I tried with rust nightly (1.4.0) and rust 1.3.0beta.

posborne commented 9 years ago

@rvlander, I apologize. It has been a little while since I have tried to build. I think there are a few things going on.

  1. The README is wrong. This issue is covered by #333. Right now, you should be able to go into the example you want to bulid and just do a cargo build, I believe.
  2. The build is failng on nightly due to fallout from https://github.com/rust-lang/rfcs/pull/1184. Changes upstream have caused extern create core to be included by default which is breaking compilation for several libs in zinc and rlibc.

I probably won't be able to get to making changes today, but I was able to reproduce a problem. Does this look like what you get when trying to compile an example?

$ cargo build
    Updating git repository `https://github.com/hackndev/rust-libcore`
    Updating git repository `https://github.com/hackndev/rlibc`
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling zinc v0.1.0 (file:///home/posborne/Projects/rust-playground/zinc/examples/blink_lpc17xx)
   Compiling core v1.0.0 (https://github.com/hackndev/rust-libcore#d9dc4f94)
   Compiling volatile_cell v1.0.0 (file:///home/posborne/Projects/rust-playground/zinc/examples/blink_lpc17xx)
   Compiling rlibc v0.1.3 (https://github.com/hackndev/rlibc?branch=zinc#0acbe22b)
/home/posborne/Projects/rust-playground/zinc/volatile_cell/lib.rs:21:1: 21:19 error: an external crate named `core` has already been imported into this module [E0259]
/home/posborne/Projects/rust-playground/zinc/volatile_cell/lib.rs:21 extern crate core;
                                                                     ^~~~~~~~~~~~~~~~~~
/home/posborne/Projects/rust-playground/zinc/volatile_cell/lib.rs:21:1: 21:19 help: run `rustc --explain E0259` to see a detailed explanation
error: aborting due to previous error
   Compiling syntaxext_lint v0.1.1
/home/posborne/.cargo/git/checkouts/rlibc-d63266f592a961ed/zinc/src/lib.rs:30:1: 30:19 error: an external crate named `core` has already been imported into this module [E0259]
/home/posborne/.cargo/git/checkouts/rlibc-d63266f592a961ed/zinc/src/lib.rs:30 extern crate core;
                                                                              ^~~~~~~~~~~~~~~~~~
/home/posborne/.cargo/git/checkouts/rlibc-d63266f592a961ed/zinc/src/lib.rs:30:1: 30:19 help: run `rustc --explain E0259` to see a detailed explanation
error: aborting due to previous error
   Compiling macro_zinc v0.1.0 (file:///home/posborne/Projects/rust-playground/zinc/examples/blink_lpc17xx)
Build failed, waiting for other jobs to finish...
Could not compile `volatile_cell`.
rvlander commented 9 years ago

Yes I have the same error.

rvlander commented 9 years ago

I have the following error now:

/home/gandre/.cargo/git/checkouts/rust-libcore-a3e1d25b35d5cd12/master/rust/src/libcore/lib.rs:123:9: 123:16 error: file for module prelude found at both prelude.rs and prelude/mod.rs /home/gandre/.cargo/git/checkouts/rust-libcore-a3e1d25b35d5cd12/master/rust/src/libcore/lib.rs:123 pub mod prelude; ^~~ /home/gandre/.cargo/git/checkouts/rust-libcore-a3e1d25b35d5cd12/master/rust/src/libcore/lib.rs:123:9: 123:16 help: delete or rename one of them to remove the ambiguity

mcoffin commented 9 years ago

@rvlander That looks to be a problem upstream with the version of nightly rust that you're using, though I could be wrong.

farcaller commented 9 years ago

rust-libcore shouldn't fail to compile. can you please try with the next nightly and report back?

rvlander commented 9 years ago

I tested with rustc 1.4.0-nightly (e822a18ae 2015-08-16)

posborne commented 9 years ago

@rvlander, what specific command are you using to build? I have seen similar errors when I forget to add on the target spec.

rvlander commented 9 years ago

cargo build in the example dir.

mcoffin commented 9 years ago

@rvlander Until I fix the Makefile for the examples, you'll have to manually add the --target flag to cargo commands to build the examples. A list of target to platform mappings can be found in the configure.ac script.

So for lpc17xx, you'd have

cargo build --target=thumbv7-none-eabi --release

A discussion of how to go about solving this inconvenience is going on in #333

rvlander commented 9 years ago

I copied the target specification file in the example dir, then launched this command. Unfortunately, i still have the same error.

rvlander commented 9 years ago

It finally built with last zinc version and last rust nightly. Thanks all.

However I have a linking error when trying to build in debug.

mcoffin commented 9 years ago

What's the error with debug? I remember running in to something like that back when I was doing #285

rvlander commented 9 years ago

This is the error I get:

error: linking with `arm-none-eabi-gcc` failed: exit code: 1
note: "arm-none-eabi-gcc" "-mcpu=cortex-m4" "-mthumb" "-Tlayout.ld" "-L" "/usr/local/lib/rustlib/thumbv7em-none-eabi/lib" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/blink_stm32f4.0.o" "-o" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/blink_stm32f4" "-Wl,--gc-sections" "-nodefaultlibs" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/deps/libzinc-d3ad4c28cae4016a.rlib" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/deps/librlibc-1fbafb63a8479a48.rlib" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/deps/libvolatile_cell-051f957da96ffddf.rlib" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/deps/libcore-59996a419f60f2f9.rlib" "-L" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug" "-L" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/deps" "-L" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/build/zinc-bc4c869fc165296a/out" "-L" "/usr/local/lib/rustlib/thumbv7em-none-eabi/lib" "-L" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/.rust/lib/thumbv7em-none-eabi" "-L" "/home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/lib/thumbv7em-none-eabi" "-Wl,-Bstatic" "-Wl,-Bdynamic" "-lm" "-lgcc" "-lnosys"
note: `__rustc_debug_gdb_scripts_section__' referenced in section `.text.main' of /home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/blink_stm32f4.0.o: defined in discarded section `.debug_gdb_scripts' of /home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/blink_stm32f4.0.o
`__rustc_debug_gdb_scripts_section__' referenced in section `.text.main' of /home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/blink_stm32f4.0.o: defined in discarded section `.debug_gdb_scripts' of /home/rvlander/CloudStation/WIP/STM32F3DISCOVERY/zinc/examples/blink_stm32f4/target/thumbv7em-none-eabi/debug/blink_stm32f4.0.o
/home/rvlander/SDKs/gcc-arm-none-eabi-4_8-2014q2/bin/../lib/gcc/arm-none-eabi/4.8.4/armv7e-m/libgcc.a(unwind-arm.o): In function `get_eit_entry':
unwind-arm.c:(.text+0x154): undefined reference to `__exidx_end'
unwind-arm.c:(.text+0x158): undefined reference to `__exidx_start'
collect2: error: ld returned 1 exit status

error: aborting due to previous error
Could not compile `blink_stm32f4`.
mcoffin commented 9 years ago

Ugh. I thought we were finally out of the woods with the debug index symbols but I guess not. @posborne you were playing around with this issue with me before too. Just tagging you so you get notifications here too.

farcaller commented 9 years ago

Hm, get_eit_entry bugging us again? I can't reproduce this at 3b4c301512b9100e6551bcd8870a1b827231a4eb and linaro gcc 4.9 (2014q4). Basically, exidx is stripped from the resulting binary as we do not support unwinding.

farcaller commented 9 years ago

@mcoffin, I believe those are not debug symbols, but "index entries for section unwinding", i.e. they are used in panic. Thing is that we shouldn't unwind at panic, we should infinite-loop there.

rvlander commented 9 years ago

I am using the gcc-arm-none-eabi-4_8-2014q2 toolchain. I will try with other toolchains and report back.

posborne commented 9 years ago

@rvlander, FWIW, I have been using the 4.9 toolchain from https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded under 14.04. Looks like there is a newer ppa available here now: https://launchpad.net/gcc-arm-embedded (assuming you are on Ubuntu).

rvlander commented 9 years ago

Just tried with 4.9-2015q2. Same error.

farcaller commented 9 years ago

Curious. Can you add them into linker script and dump the resulting linker map? I have little idea why it's being pulled in for your toolchain.

posborne commented 9 years ago

I was able to reproduce this on my mac (using arm-none-eabi-gcc 4.9) today when bringing my PWM stuff up to date. Here's the failing link command and error:

note: "arm-none-eabi-gcc" "-mcpu=cortex-m3" "-mthumb" "-Tlayout.ld" "-L" "/usr/local/lib/rustlib/thumbv7m-none-eabi/lib" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/rgb_pwm_lpc17xx.0.o" "-o" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/rgb_pwm_lpc17xx" "-Wl,--gc-sections" "-nodefaultlibs" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/deps/libzinc-fd1638775d385b8e.rlib" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/deps/librlibc-1fbafb63a8479a48.rlib" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/deps/libvolatile_cell-63ce0d9fff915f46.rlib" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/deps/libcore-59996a419f60f2f9.rlib" "-L" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug" "-L" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/deps" "-L" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/build/zinc-56e565f97e4f1398/out" "-L" "/usr/local/lib/rustlib/thumbv7m-none-eabi/lib" "-L" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/.rust/lib/thumbv7m-none-eabi" "-L" "/Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/lib/thumbv7m-none-eabi" "-Wl,-Bstatic" "-Wl,-Bdynamic" "-lm" "-lgcc" "-lnosys"
note: `__rustc_debug_gdb_scripts_section__' referenced in section `.text.main' of /Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/rgb_pwm_lpc17xx.0.o: defined in discarded section `.debug_gdb_scripts' of /Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/rgb_pwm_lpc17xx.0.o
`__rustc_debug_gdb_scripts_section__' referenced in section `.text.main' of /Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/rgb_pwm_lpc17xx.0.o: defined in discarded section `.debug_gdb_scripts' of /Users/posborne/Projects/rust-playground/zinc/examples/rgb_pwm_lpc17xx/target/thumbv7m-none-eabi/debug/rgb_pwm_lpc17xx.0.o
collect2: error: ld returned 1 exit status

Here's the generated map file with cross references: https://gist.github.com/posborne/1c68c70e5dfce94dafba

As a quick fix, I was able to get things to link with the following change. Excluding this section seems fine, but maybe somebody else more familiar with the linker knows better.

diff --git a/src/hal/layout_common.ld b/src/hal/layout_common.ld
index 7ce8590..4bf67b3 100644
--- a/src/hal/layout_common.ld
+++ b/src/hal/layout_common.ld
@@ -62,6 +62,6 @@ SECTIONS
         *(.rel.*)  /* dynamic relocations */
         *(.ARM.exidx*) /* index entries for section unwinding */
         *(.ARM.extab*) /* exception unwinding information */
-        *(.debug_gdb_scripts)
+        /* *(.debug_gdb_scripts) */
     }
 }
rvlander commented 9 years ago

@farcaller: Sorry but I am not sure of what you mean. I don't have a deep knowledge/understanding of gcc linker. How do I do what you expect from me?

posborne commented 9 years ago

@rvlander, I think I provided the info the @farcaller was asking for. To do that, I just copied the failing link command and added `"-Wl,-Map=failedlink.map,--cref". You can try the workaround in my above diff to see if that also works for you (I expect it will).

The bigger question is probably why .text.main references __rustc_debug_gdb_scripts_section__. Looking at the compiler, it appears that a reference to this section is very intentionally inserted so that the debug_gdb_scripts section is not garbage collected. What harm does including the .debug_gdb_scripts in the elf file have?

https://github.com/hackndev/zinc/commit/44a291fec8da33d1edd1bd85a1a0d94be0d85736 claims that it made the binaries too big. It will certainly increase the size of the elf file, but does this matter? Won't this and other sections be removed before any code is loaded on a target?

farcaller commented 9 years ago

It's where in elf file it lands, if you don't discard it, it follows after .text into ROM I think.

Can I have the elf with rustc_debug_gdb_scripts_section link error? I wonder if it's somehow relevant to recent rust and I really wonder why I still can't reproduce it.

posborne commented 9 years ago

@farcaller, the error prevents the elf from being generated. I can, however, provide an elf with the workaround which should have the information you need to determine if that workaround is ending up in ROM. Will probably have to wait until this evening.

farcaller commented 9 years ago

Yes, the latter one is what I want to see.

posborne commented 9 years ago

It appears that things are fine with the section included. It adds 34 bytes to the executable which is a wash with all the other losses when doing a debug build. Here's the output for empty:

$ arm-none-eabi-size -A -d target/thumbv7m-none-eabi/debug/empty
target/thumbv7m-none-eabi/debug/empty  :
section                 size        addr
.data                      0   268435456
.vector                  204           0
.debug_gdb_scripts        34         204
.text                   1164         240
.bss                       8   268435456
.ARM.attributes           45           0
.debug_str            966614           0
.debug_abbrev           2082           0
.debug_info           853988           0
.debug_ranges         106152           0
.debug_pubnames       171986           0
.debug_pubtypes       170636           0
.debug_frame          260288           0
.debug_line           313151           0
Total                2846352

Consisting of...

$ arm-none-eabi-nm --print-size --size-sort --radix=d target/thumbv7m-none-eabi/debug/empty | arm-none-eabi-c++filt
00000782 00000004 T __aeabi_unwind_cpp_pr0
00000782 00000004 T __aeabi_unwind_cpp_pr1
00000782 00000004 T __aeabi_unwind_cpp_pr2
00000792 00000006 t util::support::abort::__rust_abi
00001396 00000008 t const46726
00000782 00000010 T abort
00000764 00000018 t hal::isr::isr_cortex_m3::isr_handler_wrapper::__rust_abi
00001312 00000020 t panic_loc3322
00001344 00000020 t panic_loc3325
00001376 00000020 t panic_loc3327
00000736 00000028 T hal::stack::set_stack_limit::hce9b0f51b8cd5d09drs
00000456 00000028 t start::h1a728362648a848euaa
00000798 00000030 T rust_begin_unwind
00001216 00000031 t str3319
00000204 00000034 V __rustc_debug_gdb_scripts_section__
00000000 00000064 R ISRVectors
00001248 00000064 t str3321
00001142 00000072 T fmt::Arguments$LT$$u27$a$GT$::new_v1::h8510c3ac03f1d3c8A3Q
00000828 00000126 T panicking::panic::hc179ecda25134b78g6E
00000064 00000140 R NVICVectors
00000954 00000188 T panicking::panic_fmt::hd63abdc307a924e1J7E
00000240 00000216 t run::h7a738e43714f7950iaa
00000484 00000252 T main

The elf files (empty and and rgb_pwm_lpc17xx) can be found here: https://gist.github.com/posborne/01e937e4021c815466f7. The rgb_pwm_lpc17xx currently ends up pulling in quite a bit (.text is >32K; oddly, this wasn't the case yesterday on my mac but is the case on my Linux box).

farcaller commented 9 years ago

Is this a release build?

posborne commented 9 years ago

Both are debug builds.

farcaller commented 9 years ago

After checking the release builds they look sane to me so I guess we can move on with defining the missing symbols, they don't matter much for release binaries.

This is going to land as part of #311.

rvlander commented 9 years ago

Aren't they useful for gdb?

posborne commented 9 years ago

Yes, having debug builds work (at least for small programs where things will fit) is quite useful for gdb debugging. I'll work in the change to #311 when I get around to taking care of the next set of updates.

rvlander commented 9 years ago

@posborne, I explained myself badly. Of course gdb need debug builds.

What I understand is that the fix to the problem was to define dummy symbols so that the linker is happy. But will it affect the behaviour of gdb? Doesn't gdb need real symbols instead of dummy ones?

farcaller commented 9 years ago

Those symbols are used for unwinding, and if you got to unwinding things are horribly wrong anyway (i.e. you will trap in gdb no matter what).

posborne commented 8 years ago

This can be closed now that the docs are updated.

farcaller commented 8 years ago

Right, missed this one.

mcoffin commented 8 years ago

I'm now getting the aforementioned error. @posborne. It's probably my environment setup but it does seem odd. Tips?

I have the following error now:

/home/gandre/.cargo/git/checkouts/rust-libcore-a3e1d25b35d5cd12/master/rust/src/libcore/lib.rs:123:9: 123:16 error: file for module prelude found at both prelude.rs and prelude/mod.rs /home/gandre/.cargo/git/checkouts/rust-libcore-a3e1d25b35d5cd12/master/rust/src/libcore/lib.rs:123 pub mod prelude; ^~~ /home/gandre/.cargo/git/checkouts/rust-libcore-a3e1d25b35d5cd12/master/rust/src/libcore/lib.rs:123:9: 123:16 help: delete or rename one of them to remove the ambiguity

If someone wants to debug / help, I'll be in #zinc on Mozilla IRC later tonight.

farcaller commented 8 years ago

try removing Cargo.lock to force all the latest versions?

mcoffin commented 8 years ago

I think I've found it. The unzip directory for rust in rust-libcore can get stale versions of files removed if the rustc version changes without changes in the actual rust-libcore repo version. I'm just going to file an issue there and fix.

Explanation for Archives

cargo thinks it's fine to just rebuild using the same working directory as months ago for rust-libcore because the git commit hash is the same. However, the build script for rust-libcore is downloading and unzipping a rust tarball on every build. Unfortunately, it doesn't clean its unzipped rust directory, so stale files can hang around because the tar command is just merging the existing directory with the unzipped tarball. It's a miracle this hasn't caused issues until now, and explains why the issue has been magically fixed with time (after people upgraded cargo or multirust updates, or anything that cleared that cargo git cache.

So, good news @rvlander, you're not nuts, and this was a valid issue. We just happened to be going from a clean environment often enough for it to not cause issues.