Re: [gentoo-embedded] gcc question - entry point problem in small, static app

[Christopher Friedt]

Hi Mike,

On Tue, Mar 31, 2009 at 10:07 AM, Mike Frysinger <vapier@g.o> wrote:
> then you cant use any libraries/files from glibc or gcc because they're
> assuming a Linux environment.  that means you need to use -nostdlib.  then you
> need to provide code to setup the C runtime environment (the "start" symbol
> entry point) which will tail off to the main() function.
>
> also, the default linker script is targetting a Linux environment which means
> you'll probably also have to write your own linker script.

Thanks for your input. I built myself a toolchain for
arm-softfloat-elf, and using that toolchain, my binary is compiling
without errors with -nostdlib -nodefaultlibs -nosystemfiles -nostdinc
-nostartfiles.

In the end, I'm hoping to port Linux to a new device, but for now, I
would settle for printing out a few characters to the std. uart, to
verify that it's working.

I've tried using a WinCE executable that I wrote, but no dice. I've
tried probing some of the registers and flipping the required bits
using HaRET as well, still no results when I write to the STD_TXD.

My next attempt involves running my elf binary (test_uart) from HaRET
as if it were a kernel image, but placing the binary at the proper
entry point (specified from gcc with -e) is currently impossible with
HaRET, because it decides where to load based on the availability of
contiguous pages of memory. I'll have to add a custom environment
variable to specify exactly where to load the kernel image (something
like ENTRYADDR or LOADADDR).

HaRET is pretty useful for porting Linux (and subsequently Gentoo or
Android!) to devices that run WinCE. It's a WinCE app though, which
means that you can only compile the source with cegcc (or mingw32ce).
There are binaries available for i686, and I've created a couple of
ebuilds and overlay if anyone here is interested.

layman -f -o http://virtb.visibleassets.com:2080/layman.conf -a cegcc

Cheers,

Chris