I am trying to assemble and link an assembly program which uses C 
library functions. When I assemble and link the program using gas and ld 
  everything goes fine and the program is build properly. However when 
using GCC it wont. I'm wondering why this is happening. Below are the 
errors I get when using GCC followed by the program code

-- Using gas and ld --
roeland@rootland:$ as cpuid2.s -o cpuid2.o roeland@rootland:$ ld 
-dynamic-linker /lib/ld-linux.so.2 -o cpuid2 -lc cpuid2.o 
roeland@rootland:$ ./cpuid2
The processor Vendor ID is 'AuthenticAMD'


-- GCC errors --
roeland@rootland:$ gcc -o cpuid2 cpuid2.s
/tmp/ccHXqNul.o(.text+0x0): In function `_start':
: multiple definition of `_start'
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.text+0x0):../sysdeps/i386/elf/start.S:47: 
first defined here
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o(.text+0x18): In 
function `_start':
.../sysdeps/i386/elf/start.S:98: undefined reference to `main'
collect2: ld returned 1 exit status
roeland@rootland:$

-- Program Code --
# CPUID program 2, view the Vendor ID string using system calls
..section .data
output:
         .asciz "The processor Vendor ID is '%s'\n"

..section .bss
         .lcomm buffer, 12

..section .text
..globl _start
_start:
         movl $0, %eax
         cpuid
         movl $buffer, %edi
         movl %ebx, (%edi)
         movl %edx, 4(%edi)
         movl %ecx, 8(%edi)
         pushl $buffer
         pushl $output
         call printf
         addl $8, %esp
         pushl $0
         call exit


Can someone explain why gcc comes up with these errors? (I also tried " 
gcc -dynamic-linker /lib/ld-linux.so.2 -o cpuid2 -lc cpuid2.s" with the 
same problems)

>I am trying to assemble and link an assembly program which uses C
>library functions. When I assemble and link the program using gas and ld
>  everything goes fine and the program is build properly. However when
>using GCC it wont. I'm wondering why this is happening.
>...
>-- GCC errors --
>roeland@rootland:$ gcc -o cpuid2 cpuid2.s
>/tmp/ccHXqNul.o(.text+0x0): In function `_start':
>: multiple definition of `_start'

Note that gcc adds startup code and default libraries. crt0.o (or so)
calls main and after return exits. It is linked by default before any
other object files. You must add linker options to prevent this. Like
(untested)

$ gcc -nostartfiles -nostdlib -nodefaultlibs -ocpuid2 cpuid2.s -lc

I do not know if you can prevent linking crt0.o and use libc.

Hubble.

> $ gcc -nostartfiles -nostdlib -nodefaultlibs -ocpuid2 cpuid2.s -lc
>
> I do not know if you can prevent linking crt0.o and use libc.

Unfortunately, you often can. Doing so can produce irregular bugs. If
you don't care about portability and reliability, and if it seems to
works on your machine, then go for it. Otherwise, you must choose:
Either write your own _start and do without libc, or else use main().

b

> $ gcc -nostartfiles -nostdlib -nodefaultlibs -ocpuid2 cpuid2.s -lc
>> I do not know if you can prevent linking crt0.o and use libc.


>Unfortunately, you often can. Doing so can produce irregular bugs. If
>you don't care about portability and reliability, and if it seems to
>works on your machine, then go for it. Otherwise, you must choose:
>Either write your own _start and do without libc, or else use main().
>b

So the best way would be to replace the _start symbol with _main and
let crt0.o go in. Perhaps Roeland should write an empty main(), compile
it with gcc -S and look at the assemlby code produced by the
C-compiler.

Hubble.