I am facing a trivial prblem.
I am doing an ldr r0, _buff
in arm assembly, where _buff is defined in a c file. _buff is not static.
How should I define external linkage in assembly file (similar to extern in C)
is it required or is there anything which I am missing.
You don't need to. If the symbol can't be found in the source file, it'll be assumed to be defined elsewhere.
It's not necessary to do that. If *_buff* has been defined as global in the C file, you can compile and build the files together:
arm-none-gnuaebi-gcc -o output assembly.s cfile.c
You can also compile them separately, it's also going to work. But _buff does not exist, you will get a link error.
Related
I am getting this error when using atomthreads in cosmic c for stm8L151c6 micro controller.
clnk - symbol _archFirstThreadRestore not defined (Debug\atomkernel.o)
Ifound out that _archFirstThreadRestore is defined inside a assembler file named atomports_asm_cosmic.s linker cannot find those routines in the assembler file. How can I make linker to add the assembler file to the c code where those functions are used.
Yes got it.
I got it worked.
The problem was I have to add assembler files to the project source files. Which I didn't do.
I have an ATMEL C project (ATmega328) in ATMEL Studio 7 and need to mix in some assembly code.
I don't want to use the C inline assembly asm() directive because I want to keep it separate as a pure assembly file.
I want to include .asm to my project, but here is the thing.
For a C project it allows me to create .s or .S files. These are apparently using a different assembler than the .asm files because in .s files commands like .inc or .equ is not recognized.
However, if I rename the .s to .asm, ATMEL Studio won't invoke the assembler (as for a pure assembly project). I guess I could solve this with the Pre-Build event to manually invoke the right assembler for the .asm files.
I can stick with .s (although I prefer the .asm) file if there was a way to include all the I/O register definitions. #include <avr/io> itself doesn't generate an error but it doesn't define anything either.
#include <avr/io.h>
.global ReadFlux
ReadFlux:
ldi r24,'#'
out TCNT0,r24
in r24,TCNT0
ret
...so TCNT0 is not known and generates an error.
I need to get the assembly version of it; m328def.inc but that one can't be found and also use .equ, not recognized by the .s assembler.
What is the proper way to setup the .s so I don't have to manually define every single IO register?
or (preferably, use the .asm instead).
EDIT
So there are two assemblers; avrasm2.exe and avr-gcc.exe with the assembler-with-cpp directive. In a pure Assembly project it seems like avrasm2.exe is used and in a C/C++ project the GNU assember is used. These 2 flawors are not working in the same way, hence the confusion.
For example with avrasm2.exe I can write like this:
out DDRB,r16
but with avr-gcc.exe I have to write it like this:
out _SFR_IO_ADDR(DDRB),r16
I think the mystery has been solved for now, but I still prefere the avrasm2.exe instead.
I'm trying to get started learning basic assembly with Paul A. Carter's book "PC Assembly Language." However I'm unable to run the first example Carter provides, so I'm kind of stuck until I figure this out.
I assembled the example "first.asm" without any problem, but I can't figure out how to link these files: first.obj, driver.c, asm_io.obj into an executable. In the comment section of first.asm Carter gives these instructions for creating an executable (I'm using Windows 10, VS community 2015 developer command prompt):
; Using MS C/C++
; nasm -f win32 first.asm
; cl first.obj driver.c asm_io.obj
I'm doing exactly that but I'm getting a fatal error 2 unresolved externals, _printf and _scanf. I have every necessary file that I can think of in the same directory, and I'm compiling in that directory.
Driver.c calls the function defined in and it uses a header file called "CDECL.h"; I have this file in my directory, but I don't understand much about this header file. I wonder if the problem is here. I haven't altered it or anything. I assembled asm_io.asm according to Dr. Carter's instructions.
Not too far into asm_io.asm is see this:
extern _scanf, _printf, _getchar, _putchar, _fputs
So here are the unresolved externals. Shouldn't they be defined in stdio.h? Driver.c includes stdio.h, shouldn't the linker be able to resolve these symbols be looking at stdio.h? What might I be missing?
ps. I'm new to programming in general, and this is my first stack overflow question. I'm open to any and all criticism/feedback. I'll provide more information if you need it, I just didn't want to post a massive wall of text and code if not necessary.
Welcome to SO. You need to understand:-
The difference between a header file, e.g.
foo.h // C or maybe C++ header file)
and a library, e.g.
foo.lib foo.dll // Windows
libfoo.a, libfoo.so // Unix/Linux
that implements the calling interface that is (merely) described in a header file.
The difference between compiling or assembling a source file, e.g.
bar.c // C source file
bar.asm // Assembly source, Windows
bar.s // Assembly source, Unix/Linux
to make an object file. e.g.
bar.obj // Windows
bar.o // Unix/Linux
and linking object files and libraries together make a complete executable.
Linking can succeed only if the linker is supplied with (or knows by default)
the names and locations of object files and/or libraries that provide
implementations of all the functions that are called in the program - including
functions whose calling interfaces are described in header files. Otherwise
unresolved symbol errors ensue.
Research these points and you'll quickly get yourself unstuck. See this
pretty good introductory tutorial, which although it is about getting
started with the GNU Compiler Collection rather
than with assembly language programming, will clarify the principles
and distinctions you need to grasp.
How to write function at particular memory location in flash memory? Is there any directive for that? Do i need particular linker?
If you are using keil ide you can place a function at a specific address using .ARM.__at_address as the section name. To place the function add at 0x20000, specify:
int add(int n1,int n2) __attribute__((section(".ARM.__at_0x20000")));
int add(int n1,int n2)
{
return n1+n2;
}
Do you use the keil toolchain?
If yes, perhaps http://www.keil.com/support/docs/359.htm helps.
Edit:
The .obj file is generated by the compiler. I am not sure what you mean with 'how can i configure .obj file'.
The linker mentioned above takes the obj files, links them together and places code and variables.
You should start with a project which compiles and links without errors.
Then you have:
- Some c files. One of them with your function.
- A linkfile with the settings for the linker.
- A makefile or some kind of batchfile which calls compiler and linker with the necessary arguments.
If you have that, you can look into the m51 file for the name of the symbol for your function.
The m51 file is a textfile generated by the lx51 linker with interesting information about which symbols are there and what the linker has done with them.
The keil documentation for the linker I mentioned says: The compiler creates a symbol name for the function using the following format: ?PR?function_name?file_name.
This means: You will find the names of all functions of your project in the m51 file. If your function is in file file_x and named func_x. The symbol name will be PR?func_x?file_x
In http://www.keil.com/support/man/docs/lx51/lx51_segments.htm you can find some information about the usage of the SEGMENTS directive of the lx51 linker. According to that:
SEGMENTS (PR?func_x?file_x(C:0x1234))
should place your function to address 0x1234 in code memory.
Actually I have no keil toolchain. Therefore I cannot test all that myself.
But I am sure that you can manage that yourself if you start with a simple working example, change things step by step and check what happens.
Good Luck.
Helmut
Use ORG directive.
For example, for a function to start at location 2000H
ORG 2000H
MY_FUNC:
: YOUR CODE HERE
RET
I'm using CppUTest to test the C code defined in a fornol.c source file. That file defines the main production main() function.
I also have an AllTests.cpp file that also has a main() function, but that main() is supposed to be used only when running the unit tests.
AllTests.cpp gets compiled to a .o file, whereas fornol.c gets compiled to a libfornol.a archive.
Then CppUTest tries to link everything together, but here is what I get instead:
Linking fornol_tests
cc -o fornol_tests objs/tests/AllTests.o objs/tests/FornolTests.o lib/libfornol.a ../../CppUTest/lib/libCppUTest.a ../../CppUTest/lib/libCppUTestExt.a -lstdc++ -lgcov
lib/libfornol.a(fornol.o): In function `main':
/home/dlindelof/Work/endor/nol/fornol/fornol.c:453: multiple definition of `main'
objs/tests/AllTests.o:/home/dlindelof/Work/endor/nol/fornol/tests/AllTests.cpp:4: first defined here
collect2: ld returned 1 exit status
It looks as if the main() function defined in fornol.c and present in the archive libfornol.a conflicts with the main() defined in AllTests.cpp. But my understanding was that archive/library files are searched only if/when a given symbol hasn't been referenced yet. It should therefore not be a problem to have the same symbol defined more than once, provided all definitions are in archive/library files.
What am I doing wrong here?
You need to remove the main() from AllTests.cpp and put it in its own source file.
When a linker links in a library, it can't split object files in the library; it has to either link or omit each object file in the library as a unit. (I know LLVM is different, but that's another topic.) This is why, if you look at the source for a library like glibc, each function gets its own source file.
So what's happening to you is that the linker needs to pull in an object file (fornol.o) from the library (libfornol.a) to satisfy dependencies, but that object file carries a duplicate symbol with it (main).
It's perfectly okay to put test code in a library (we do this routinely where I work), but keep it in its own source files (we traditionally use main.cc). (This is a better test anyway, because test code should not have access to static-declared symbols.)
A library is supposed not to have a main() function as it is a library.
You should remove that main() from fornol.c and compile it again.
main() is the entry point of an executable file's source code, since a library (especially a static ".a" library) is only pre-compiled source code, you cannot use a main in there.
If you want a main production entry point of your library you could rename the main() in fornol.c to something more explicit and less reserved such as "fornolMain()" for example.
A static library is compiled in your binary executable and thus is not searched only if the symbol is loaded. It is exactly the same as compiling fornol.c and linking fornol.o and your other .o