Embedded use of gcc on Windows - gcc

Question

I am trying to use gcc for embedded program generation. The gcc came from the Mingw toolset,
which is the same gcc I use to generate regular applications under Windows. I am trying to
generate a straight binary, located at 0x1000, for use in an embedded i386/32 bit system.
It gets tested under Bochs.
My linker file looks like this:
/* a list of files to link */
INPUT(test.o)
/* output format */
OUTPUT_FORMAT("pe-i386")
/* output filename */
/* OUTPUT_FILENAME("test.out") */
/* list of our memory sections */
MEMORY
{
ram : o = 0x1000, l = 256k
}
/* place sections */
SECTIONS
{
/* code and constants */
.text :
{
__text_start = .;
*(.text)
*(.strings)
__text_end = .;
} > ram
/* initialized data */
.data :
{
__data_start = .;
*(.data)
__data_end = .;
} > ram
/* uninitialized data */
.bss :
{
__bss_start = . ;
*(.bss)
*(COMMON)
__bss_end = . ;
} > ram
}
Basically, it means concatenate everything to a target address in ram at 0x1000.
If I select any target besides a PE file I get:
Cannot perform PE operations on a non PE file...
Which other messages here say is a known issue with ld on windows. So I perform another
step to create a binary using objcopy, which works fine.
Here are the output sections:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000038 ffc01000 ffc01000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rdata 00000010 ffc02000 ffc02000 00002000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .eh_frame 00000038 ffc03000 ffc03000 00003000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
So the sections are being aligned on a page frame address (4kb), which I like.
Here is the disassembly of the .text frame:
test.pe: file format pe-i386
Disassembly of section .text:
ffc01000 <_crap>:
ffc01000: 55 push ebp
ffc01001: 89 e5 mov ebp,esp
ffc01003: 83 ec 10 sub esp,0x10
ffc01006: c7 45 f8 00 20 00 00 mov DWORD PTR [ebp-0x8],0x2000
ffc0100d: c7 45 fc 00 80 0b 00 mov DWORD PTR [ebp-0x4],0xb8000
ffc01014: eb 14 jmp ffc0102a <_crap+0x2a>
ffc01016: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
ffc01019: 8a 00 mov al,BYTE PTR [eax]
ffc0101b: 66 98 cbw
ffc0101d: 8b 55 fc mov edx,DWORD PTR [ebp-0x4]
ffc01020: 66 89 02 mov WORD PTR [edx],ax
ffc01023: 83 45 fc 02 add DWORD PTR [ebp-0x4],0x2
ffc01027: ff 45 f8 inc DWORD PTR [ebp-0x8]
ffc0102a: 83 7d f8 00 cmp DWORD PTR [ebp-0x8],0x0
ffc0102e: 75 e6 jne ffc01016 <_crap+0x16>
ffc01030: b8 00 00 00 00 mov eax,0x0
ffc01035: c9 leave
ffc01036: c3 ret
ffc01037: 90 nop
So I have no idea how or why it located the code at 0xffc01000, that is not what I
specified in the linker instruction file.
With the idea that this was some artifact of the PE file format, I tried to select
other output formats like elf, but if I do that I hit the "cannot perform PE operations
on non PE output file" bug.
The questions are:
Why does it locate to 0xffc01000? This doesn't appear to make sense even in the context
of a Windows program.
Is there a way to properly locate the program?
Do I need to use a i386 gcc build that is not tied to Windows?
Thank you,
Scott Moore