Simplify compile process

[bharrisau]

Changes to libcore means we need to do the compile in less passes.

Added the three new lang items, pulled support into zinc, app is still
the main entry point but it produces the .elf without a second call to
ld.

There has been a large size regression, the majority of it is from
libcore pulling in the string formatting functions for error handling.
I will submit a patch to provide a cfg flag for building libcore
with simpler errors.

[teachop]

@bharrisau I see this builds fine because Travis CI is "All is well" and the output looks happy. I have build failures on a59ac75 lpc17xx build_all with ld undefined symbol "isr_nmi" referenced in expression. Any ideas what I have wrong here?

[bharrisau]

I'd suggest deleting the build (and maybe thirdparty) folder and trying
again. That error is due to the default fault handler symbol missing.
On 27/05/2014 5:55 am, "teachop" notifications@github.com wrote:

@bharrisau https://github.com/bharrisau I see this builds fine because
Travis CI is "All is well" and the output looks happy. I have build
failures on a59ac75 a59ac75lpc17xx build_all with ld undefined symbol "isr_nmi" referenced in
expression. Any ideas what I have wrong here?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/41#issuecomment-44216024
.

[bharrisau]

I'm merging this so I can continue working. I hope this way of building is ok @farcaller, and my formatting/changes to your ruby stuff is not too hackish. Hopefully the size regressions are handled upstream so we don't need to patch failure.rs.

[teachop]

@bharrisau sorry my problem was unrelated. The link phase works fine on Linux and fails on OS X. No idea why, the link commands from rake and rustc look identical except for the /Users /home path bit.

[bharrisau]

@teachop Are you saying this doesn't build on OS X? If so I'll try changing back to calling the linker separately.

[teachop]

@bharrisau Correct it doesn't build on OS X, but I am not saying this change resulted in that state of affairs. I tried running the link line directly, same command line that rustc was generating, and it didn't work. So at that point it didn't seem related. I tried wiping build and third party, updating the rustc nightly, and two different builds of the cross toolchain from launchpad.

[by the way thanks to you and @farcaller for working on this, it is nice to really be able to consider something to top C on embedded after 30 years in this field]

[bharrisau]

Ok, I'll play with it anyway tonight (in 12 hours time). If I can get it going with a static lib it will mean I've changed less things in this PR.

[bharrisau]

I wasn't able to get it working as a static lib. I have moved the default fault handler to the support.rs file, but I'm not sure what/why it is being culled for you. I'm assuming the OSX linker has different requirements for garbage collection than the Linux one (one is -deadstrip the other is --gc-sections). I'll have to research some more into how to prevent a section from being eaten.

Just to test, can you please have a go with the newest commit. I'm using a dirty hack to prevent the handler being GC'd by the linker. If this doesn't work then I'll assume the OSX linker doesn't support the PROVIDES trick I'm using in the linker file.

[teachop]

Thanks @bharrisau I will give it a whirl in a few hours. Last night I couldn't make at all due to a .cpp file issue in thirdparty, hopefully that is fixed upstream.

[teachop]

Unfortunately wasn't able to get far enough to test this. It is failing to build both Linux and OS X in the third party. When I have time will checkout a prior version maybe. It goes like this at the moment:

Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function init, file /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/llvm/lib/IR/Instructions.cpp, line 281.

[bharrisau]

Could try make clean; ./configure just to make sure llvm is in a
consistent state and the submodule is updated.

[teachop]

No change. Tried clone / checkout from scratch too. @bharrisau If you delete the thirdparty and build directories does it rake error free?

[teachop]

Ok sorry rustc nightly 5/26 caused the Assertion Failed, 5/29 resolved that one. So back to the test. The complaint is the same with 3a128f7.

/Users/teachop/Projects/zinc/src/hal/lpc17xx/layout.ld:3: undefined symbol `isr_nmi' referenced in expression

What is the way to dump crate contents and examine input to the linker. I tried rustc -Z ls and there isn't much output.

[bharrisau]

Can you just send me the version string of the linker. I think it might be
an issue with the PROVIDE() statements I'm using in the linker script.

[teachop]

[Edit: see if I can fix the formatting]

teachop/usr/local/arm/bin$ ./arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

teachop/usr/local/arm/bin$ ./arm-none-eabi-ld --version
GNU ld (GNU Tools for ARM Embedded Processors) 2.23.2.20131129
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

[bharrisau]

There is a newer version of the tools you can try. Though the binutils
version should be the same so it shouldn't change anything (but who knows).

[teachop]

Same result. I need to stick with Linux, this is wasting your valuable time.

Admitting I know nothing of these matters does this make sense: It cannot work on OSX. The triple cannot be thumbv7m-none-eabi as it is unknown OS. So it is set thumbv7em-linux-eabi to allow it to run. But this generates the wrong linker options and thus really "isr_nmi" is only guilty of being first. And -darwin- gives out a segmented stack support error.

[farcaller]

I'll look into this today right after I compile a fresh rustc. I can assure you that OS X is one of the supported build targets :)

[bharrisau]

That shouldn't be the issue (the target is still 'linux', though really it
is baremetal). It is just a little annoying that I don't have OS X to debug
it with (I should probably vagrant up a OS X box, if that is possible).

The only other thing I can think of trying is adding a KEEP() for the
default error handler in the linker script to make sure it isn't GC'd. That
or there is some issue happening on your box.

[bharrisau]

I've added a keep directive for the default isr. Nothing else should have change since this was "last working".

[teachop]

Thanks @bharrisau, same situation. I do wonder if juking the rustc to target "none" by way of "linux" ends up out of sorts on OS X as the rustc code has plenty of places where it switches on Os. But I am not knowledgable on this things!

[farcaller]

Ah, apparently this fixes the problem I "fixed" in #43.

[farcaller]

Change this to a simpler if File.extname(t.name) == '.elf', it's like you're trying to write ruby in rust style 😄

[farcaller]

@bharrisau what is a known good ld version? I know the problem with undefined symbolisr_nmi'`, it happens because ld cannot process rlibs due to extra files silently ignoring them.

[bharrisau]

My ld version is GNU ld (GNU Tools for ARM Embedded Processors) 2.23.2.20131129.

Can you explain the issue a little more? I don't get why the same ld with the same input is behaving differently just because of the host OS.

[farcaller]

I've tried building 2.24.51.20140531 from scratch, and it still fails the same way.

I had trapped on this a few months ago and there was a discussion on IRC that this could be a problem with gnu ld failing to read the archive due to extra rust files in it.

Let's maybe merge #43 instead to get us back on green. I don't like the duplicate definition of lang items, but that could be extracted to a module.

[bharrisau]

Yeah, I'm fine with some hacks while this is still a work in progress.