Can't link an assembly file (.s) with GCC on macOS Sierra - c

I have 2 files to compile.
The first is main.c and the 2nd is a function that does sums and multiplications in assembly (work.s).
This is the code :
main.c file:
#include <stdio.h>
short work();
int main() {
short z = work();
printf("work(); -> %hd\n", z);
return 0;
}
work.s file:
.globl work;
work :
xorl %eax,%eax;
xorl %ecx,%ecx;
movw $20,%ax;
subw $2,%ax;
movw $7,%cx;
addw $3,%cx;
movw $10,%cx;
subw $3,%cx;
shl $1,%cx;
addw %cx,%ax;
ret;
From command line using gcc : gcc -m32 main.c work.s -o main
This is the output :
Undefined symbols for architecture i386:
"_work", referenced from:
_main in main-fbbcca.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
While on Linux with same files and commands it works, why and how I can fix it?

Maybe change your global to the name gcc is looking for?
.globl _work;
_work :
...
There are other approaches, too:
https://montcs.bloomu.edu/~bobmon/Code/Asm.and.C/C-asm/Asm-C-example0.shtml
<= Different compiler, same principles...

In work.s, change work to _work both places it appears. The compiler prefixes an underscore to C names. Assembly language is more bare bones, so you have to prefix the underscore yourself.

Related

Trouble with C compilation via gcc command line

I'm currently trying to get into the basics regarding C-compilation without the use of an IDE.
As I only learned C- and embedded-programming with an IDE I thought it would be a good idea to learn and give me a better understanding of how the whole build process is working behind the scenes.
I mainly want to learn how to implement a complete IDEless toolchain for an STM32 controller.
So my idea was to start simple and try to understand the C-only build toolchain and its possible configurations. For this purpose I searched for tutorials and found this and this one.
I tried to follow along the first tutorial on my windows system but encountered some problems quite early that I have trouble understanding.
I created the following hello.c testfile:
#include <stdio.h>
#include <stdint.h>
int main ( void )
{
printf("Hello World!\n");
return 0;
}
First I tried the simple full compilation using gcc -o hello.exe hello.c (1.6 from the tutorial)
Everything works fine, so I decided to test the compilation steps one after the other (1.7 from the tutorial)
I called all commands in the following order:
cpp hello.c > hello.i (preprocessing) -> gcc -S hello.i (Compilation) -> as -o hello.o hello.s (Assembly) -> ld -o hello.exe hello.o (Linking)
Every step until the linking seems to work but the linker gives me the following errors:
ld: hello.o:hello.c:(.text+0xa): undefined reference to `__main' ld:
hello.o:hello.c:(.text+0x47): undefined reference to `puts' ld:
hello.o:hello.c:(.text+0x5c): undefined reference to `printf'
Did I do something wrong here? And is there a reason the ">" operator is used for preprocessing and assembling but not if I just compile using gcc -o hello.exe hello.c
Do one even use these steps seperately that often?
I read that instead of cpp hello.c > hello.i I could also use gcc -E main.c > main.i so why use the cpp command, are there any advantages?
Next I set this problem aside and tried to add includes.
For this purpose I created the following 2 files:
myFunc.c:
uint8_t myFunc( uint8_t param )
{
uint8_t retVal = 0;
retVal = param + 1;
return retVal;
}
myFunc.h
#include <stdint.h>
uint8_t myFunc( uint8_t param );
And changed the hello.c to:
#include <stdio.h>
#include <stdint.h>
#include "myFunc.h"
int main ( void )
{
uint8_t testVal = 0;
testVal = myFunc(testVal);
printf("Hello World!\n");
printf("Test Value is %d \n", testVal);
return 0;
}
I first tried the gcc -o hello.exe hello.c but get the error:
undefined reference to `myFunc' collect2.exe: error: ld returned 1 exit status
So I figured I should add the include path (even if it is the same directory).
After a short search and the help of the second site I tried gcc -Wall -v -IC:\Users\User\Desktop\C-Only_Toolchain hello.c -o hello.exe
But get the same error...
Is there something wrong with the way my include paths are added? (obviously yes)
Lastly I tried to test the GNU make command from the tutorial.
I opened the editor and inserted all contents shown in the tutorial.
As the editor saves the file as a .txt editor I tried to just delete the file extension.
The makefile looks like this:
all: hello.exe
hello.exe: hello.o
gcc -o hello.exe hello.o
hello.o: hello.c
gcc -c hello.c
clean:
rm hello.o hello.exe
But if I enter make in my console I get the error that the command "make" is written incorrectly or could not be found.
I used tab for the indentation just as the tutorial suggests but it will not even recognize that there is a makefile.
Is this because it was originally a .txt file before I deleted the extension?
I would be happy if someone could help me with my confusing regarding this rather simple issues...
Furthermore I would be very thankful if you have some good suggestions on how to get into this topic more efficiently or have some good sources to share.
Thank you in advance and stay healthy :)
Best Regards
Evox402
So, these are a lot of questions.
(In the following I use linux, so some outputs are just similar, not identical, like paths and the assembly output, but because of your usage of gcc, it's quite transferable to windows).
I called all commands in the following order: cpp hello.c > hello.i (preprocessing) -> gcc -S hello.i (Compilation) -> as -o hello.o hello.s (Assembly) -> ld -o hello.exe hello.o (Linking)
As a repetition: What are you doing here?
cpp hello.c > hello.i
You run the preprocessor over the C file. It just does a text-replace of macros/ #defines and includes files.
This looks like this. (A bit shortened as it has around 800 lines)
...Snip....
struct _IO_FILE;
typedef struct _IO_FILE FILE;
struct _IO_FILE
{
int _flags;
char *_IO_read_ptr;
char *_IO_read_end;
char *_IO_read_base;
char *_IO_write_base;
char *_IO_write_ptr;
char *_IO_write_end;
char *_IO_buf_base;
char *_IO_buf_end;
char *_IO_save_base;
char *_IO_backup_base;
char *_IO_save_end;
struct _IO_marker *_markers;
struct _IO_FILE *_chain;
int _fileno;
int _flags2;
__off_t _old_offset;
unsigned short _cur_column;
signed char _vtable_offset;
char _shortbuf[1];
_IO_lock_t *_lock;
__off64_t _offset;
struct _IO_codecvt *_codecvt;
struct _IO_wide_data *_wide_data;
struct _IO_FILE *_freeres_list;
void *_freeres_buf;
size_t __pad5;
int _mode;
char _unused2[15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)];
};
extern FILE *stdin;
extern FILE *stdout;
extern FILE *stderr;
...Snip...
extern int printf (const char *__restrict __format, ...);
...Snip...
int main ( void )
{
printf("Hello World!\n");
return 0;
}
Now all important definitions are included, so the C compiler can run.
gcc -S hello.i.
It just converts your C code to assembly. (It will look a bit different on windows)
.file "hello.c"
.text
.section .rodata
.LC0:
.string "Hello World!"
.text
.globl main
.type main, #function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
leaq .LC0(%rip), %rdi
call puts#PLT
movl $0, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Debian 10.2.0-17) 10.2.0"
.section .note.GNU-stack,"",#progbits
Now you have to convert the assembly code to machine code:
as -o hello.o hello.s
This command just generates an so called object file with your code and important metadata, the linker will need.
ld -o hello.exe hello.o
Now you invoke the linker with your object file as argument and hello.exe as output file. It will look for the entry point (_start on linux-like, WinMain for example on windows, or sometimes _main).
But also the functions from the C-standard-library are missing.
But why? You don't say the linker, that you want to include it. If you invoke the linker ld as explicit as you did, you have to pass all libraries you want to include.
You have to add for example -lc to include the stdlib, and so on.
Did I do something wrong here?
You just forgot to add the C library to the libraries the linker should link with your object-file.
And is there a reason the ">" operator is used for preprocessing
> is not from cpp. It is from the shell. Try running without > hello.i. The preprocessor will just output it on the console. The > redirects to the specified file (Here hello.i).
I could also use gcc -E main.c > main.i so why use the cpp command, are there any advantages?
There is no difference. gcc calls the preprocessor internally.
Do one even use these steps seperately that often?
These steps are sometimes used in makefiles, but not as separated as you did, but often only in compiling+linking as two separate steps to reduce compile-time.
first tried the gcc -o hello.exe hello.c but get the error:
It compiles, the C compiler knows, there is at least a definition for myFunc and because of this, it emits valid assembly code.
But the linker, as soon as it resolves the references to functions, it doesn't find it and emits the error.
You have to add the myFunc.c to your commandline:
gcc -o hello.exe hello.c myFunc.c
But if I enter make in my console I get the error that the command "make" is written incorrectly or could not be found. I used tab for the indentation just as the tutorial suggests but it will not even recognize that there is a makefile. Is this because it was originally a .txt file before I deleted the extension?
You have to add the directory of make.exe to the path.
Suppose it has the path:
C:\Foo\bar\baz\make.exe
Then you add it to the path (Execute it in the commandline):
set PATH=%PATH%;C:\Foo\bar\baz
This will only work until you close the commandline, or you can set it permanently as outlined here for example.

Call an assembler function from C code in linux [duplicate]

This question already has answers here:
32-bit absolute addresses no longer allowed in x86-64 Linux?
(1 answer)
What happens if you use the 32-bit int 0x80 Linux ABI in 64-bit code?
(1 answer)
Assembling 32-bit binaries on a 64-bit system (GNU toolchain)
(2 answers)
Closed 3 years ago.
I want to call a print function from my C program.
assembler prog:
#test.s
.text
.global _start
.global print
.type print, #function
_start:
call print
# and exit.
movl $0,%ebx # first argument: exit code.
movl $1,%eax # system call number (sys_exit).
int $0x80 # call kernel.
print:
# write our string to stdout.
movl $len,%edx # third argument: message length.
movl $msg,%ecx # second argument: pointer to message to write.
movl $1,%ebx # first argument: file handle (stdout).
movl $4,%eax # system call number (sys_write).
int $0x80 # call kernel.
mov $0, %eax
ret
.data
msg:
.ascii "Hello, world!\n" # the string to print.
len = . - msg # length of the string.
I can assemble and link it using:
$as test.s -o test.o
$ld test.o -o test
And I can execute it as a program, and it outputs "Hello, world!"
But when I tried to call a print from C code like this:
#include <stdio.h>
extern int print();
int main(){
int g;
g = print();
printf("Hello from c!, %d\n", g);
}
It was compiled using:
$gcc -c main.c test
It just prints "Hello from c, 13", that means that the function was called and return a number of chars, but does not print anything!
What am I doing wrong?
P.S.
When I trying to compile prog like this:
$as test.s -o test.o
$gcc -c main.c -o main.o
$gcc main.c test.o
I have a error:
/usr/bin/ld: test.o: in function `_start':
(.text+0x0): multiple definition of `_start'; /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/Scrt1.o:(.text+0x0): first defined here
/usr/bin/ld: test.o: relocation R_X86_64_32 against `.data' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
Ok, done! Thanks clearlight
I can compile all use
$as test.s -o test.o
$gcc -c main.c -o main.o
$gcc -no-pie main.c test.o
And all will work fine!

Undefined reference error in C external asm is included in C

I am including external asm into c, when I try to compile I am getting error.
I am compiling c file like this - g++ testing.c
Error:
cc0FHCkn.o:testing.c:(.text+0xe): undefined reference to helloWorld
collect2.exe: error: ld returned 1 exit status
C code:
#include<stdio.h>
extern "C" int helloWorld();
int main() {
printf("Its - ",helloWorld());
}
ASM code:
.code
helloWorld proc
mov rax, 123
ret
helloWorld endp
end
Note : I use that answer to be able to say more than it is possible through a remark, and using gcc.
First, just doing g++ testing.c g++ is not able to link with the assembler file which is not specified, so of course helloWorld is missing.
If I have the file hw.c :
int helloWorld()
{
return 123;
}
I ask to produce the source assembler through the option -S (I also use -O to reduce the assembler source size), so I do not have to write the assembler file by hand and I am sure it is compatible with gcc :
/tmp % gcc -O -S hw.c
That produced the file hw.s :
/tmp % cat hw.s
.file "hw.c"
.text
.globl helloWorld
.type helloWorld, #function
helloWorld:
.LFB0:
.cfi_startproc
movl $123, %eax
ret
.cfi_endproc
.LFE0:
.size helloWorld, .-helloWorld
.ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-16)"
.section .note.GNU-stack,"",#progbits
/tmp %
Also having the file m.c :
#include <stdio.h>
extern int helloWorld();
int main()
{
printf("%d\n", helloWorld());
return 0;
}
I can do :
/tmp % gcc m.c hw.s
/tmp % ./a.out
123
I propose you to do the same as, write helloWorld in C then generate the assembler with option -S, doing that you are sure to follow the gcc requirements in the function definition
1.) Create an ELF object file from the assembly file
nasm -f elf64 -o assembly.o assembly.asm
2.) Create an ELF object file of testing.c file
gcc -c testing.c -o testing.o
3.) Link ELF object file together to create final executable file.
gcc -o testing assembly.o testing.o
4.) Run final executable file
./testing
use extern int hellowrold();

GNU Linker and architecture i386

So I'm running on OS X and I want to link two Mach-O objects i386.
The first is generated from NASM (it's an assembly file)
nasm -f macho -o kernel.o kernel.asm
The second is generated from GCC
gcc -c -arch i386 screen.c
But when I try to link them...
ld -o myprogram screen.o kernel.o
...I get this error :
Undefined symbols for architecture i386:
"print", referenced from:
start in kernel.o
ld: symbol(s) not found for inferred architecture i386
I don't understand why, because my two files are Mach-O object i386 :
$ file screen.o
screen.o: Mach-O object i386
$ file kernel.o
kernel.o: Mach-O object i386
If you need it, here's kernel.asm :
[BITS 32]
EXTERN print
GLOBAL start
start:
mov eax, msg
push eax
call print
pop eax
end:
jmp end
msg db 'Hello world!', 10, 0
And here's screen.c :
void putcar(uchar c)
{
/* Some code here */
}
void print(char *string)
{
while(*string != 0){
putcar(*string);
string++;
}
}
You need to use the symbol _print in your asm file, i.e.
start:
mov eax, msg
push eax
call _print
pop eax
This is because C function names get a leading underscore when compiled.

Linking error when compiling basic x86 code with gcc

I am attempting to write very basic x86 code and call it in a C program. I'm running OSX 10.8.2. Here is the code I have:
start.c:
#include <stdio.h>
void _main(); // inform the compiler that Main is an external function
int main(int argc, char **argv) {
_main();
return 0;
}
code.s
.text
.globl _main
_main:
ret
I run the following commands to attempt compilation:
gcc -c -o code.o code.s
gcc -c -o start.o start.c
gcc -o start start.o code.o
Which then returns this output after the final command:
Undefined symbols for architecture x86_64:
"__main", referenced from:
_main in start.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
Am I missing something in my compiler calls? Do I need to update something/install something different? I just can't find a definitive answer anywhere since this is such a general output. Thanks!
You need an extra underscore in your asm _main symbol:
.text
.globl __main
__main:
ret
C symbols get an underscore prefix when compiled, so your C main is actually _main and an extern C _main actually needs to be defined as __main if you write it in asm.

Resources