I compiled this simple code (small.c)

int main()
{
 unsigned char x;

 x = 10;
 
 return 0;
}

with 'gcc small.c -osmall", expecting to find the compiled code somewhere in the binary (opening it with an hexeditor).

But surprisingly, when I scrolled at offset 0x400 (where the code in a PE should start) I found a lot of codes much more than I expected. Plus, after them, there's a 'space' of zeroed bytes, then

and again, more forward in the file

How do I get rid of them? I tried adding -static but nothing changes.
I also tried some target specific switches (obtained with --target-help) but if I use, i.e., '--disable-auto-import' I get

Where does that 'f' come from?
I'm on Windows using gcc 3.4.2

Yup.
MinGW needs to do a lot of trickery, for instance with commandline options (wildcard expansion), before it transfers control to your main. I don't think you can get around that.

--longargumentname is equivalent to -flongargumentname.

Yes, the starting point for all programs in Win32 is a function with the same calling conventions as WinMain (for extremely pedantic purposes, this function need not be named WinMain, but must have the same form). In order for MinGW to simulate an "ANSI environment" -- meaning an "int main" environment, it has to generate a stub function of the WinMain form and then convert command line arguments into the argc/argv format before calling main. Also compilers usually generate code to initialize and deinitalize their C/C++ runtime libraries whether or not you use them (unless you use some rarely used options to remove this), so you might be seeing the results for this process.

If you optimized your code, likely you would see absolutely nothing generated for your main function because you never use x, so the compiler can remove it entirely as the code is useless (it defines useless as any code that does not have side-effects).

You can, I think, if you write your own crt0.o and use -fno-builtin, -nostdinc, -nostdlib and some other options which I can't remember offhand.

Pete

[edit] For starters, you should link with -s to strip symbols from the exe!

Comparing the object file with the executable generated, all that comes after the actual instructions. I think it all is added when linking.

There are so many switches... none could help?

So why it is an unrecognized option?

[edit] Pete, you posted while I was writing mine

-fno-builtin didn't worked, the garbage is still there. I'm not using any function call, how can gcc be so stupid and link with any library at all?

Are you sure it exists? I can't find it in my manpage (different platform, but still)...

I attached the help. That switch is in the last lines

Have a look at this for extreme examples
http://www.ubergeek.org/~breadbox/software/tiny/home.html

Pete

[edit] That option is a linker option, try -Wl,--disable-auto-import
(no space between ',' and '-' )
.. might work

Peter is right, you can do it. We used GCC as part of a class assignment of writing a machine and OS emulator of some old architecture (I think it might have been VAX or PDP or something). So because we were using Solaris-based GCC to generate the code, we had to include our own crt0.o and set a bunch of flags (we couldn't use any C library calls since we were writing our own OS-kernel, so we had to call those functions manually in ASM).

Anyway, the point is that it is possible.

Now, if your only goal is to see generated ASM output from your program, you do know that there is an option to do this in GCC?

Yes i do

These days I'm playing with boot sector code (I don't know if you saw my other thread about some troubles I had). It would be nice if I could write simple programs in C, compile them and then load them directly into memory to be executed. This will need a custom I/O library to link to when I'll use I/O functions (any suggestion/link is welcome, of course ).

I'd like to not use assembly for all this stuff, it will make things easier.

[edit]

Yes! Thanks a lot! It didn't removed the garbage but now I can try all those switches

[edit2]

I'm surfing Gcc documentation. This is interesting:

Looks like we can use Intel syntax with gcc

I think I got it:
gcc small.c -osmall -nostartfiles -nodefaultlibs -nostdlib
They could be more than I need, but that's not a problem.

This instead is one: the above compile command gives this:

While the first is a warning and I think I could provide an _alloca function (I do not know how to atm, but I'll figure it out), what about the undefined '__main'?

[edit3]

I got rid of the undefined '_alloca' and '__main':

Am I on the right path?

I was googling for _mainCRTStartup and someone said that you should link with:

-e _mainCRTStartup

Thanks.

Actually I'm trying to make code that will work when directly loaded in RAM (with no OS at all, no libc & friends), in real or protected mode. So, the real issue is to put the right parameters (along with proper instructions) to make gcc produce the right code.

I resolved those undefined troubles, when I'll be home I'll post the code.

I have troubles with the output: using strip I removed all the headers and symbols etc, now I have just the code (which I still need to undestard how to relocate, but that's another problem) with a lot of 0x00 at the end (and some 0xFF).

While this could be worked around with a 'jmp $' (or 'jmp .' in as, if that's the same thing ) it is not nice.

I just remembered another issue: I was fighting with gcc with the parameter '--oformat', which wants a bfdformat. I didn't understood how to use it, I want it to output a binary file. Objdump -info says I support 'binary' which works fine with strip ('strip --output-target=binary').

Any idea?

[edit]

Here's the code that doesn't produce the warnings about undefined references