I'm trying to use a #define value from a C header file in my boot
assembly file.
For example, say I have "#define VERSION 0x01020304" in file version.h.
In Boot.s I'd like to use ".word VERSION" to place the version constant
at a specific location.
To begin with I have boot.s and everything compiles successfully. When
I rename boot.s to boot.S (to enable preprocessing on the assembly file)
and attempt to complile, I get a warning from the linker "warning:
cannot find entry symbol _reset_handler; not setting start address".
Why is the preprocessor interfering with the linker finding
_reset_handler in Boot.S?
Also, if I attempt to call routines defined in the boot.S file from a .c
file they are not found when preprocessing is enabled. For example, the
line "asm volatile ("B _vectors");" gets the error "undefined
reference to `_vectors'" when preprocessing is enabled, but compiles
successfully when I rename boot.S back to boot.s
What am I missing here?
jdupre wrote: > Why is the preprocessor interfering with the linker finding > _reset_handler in Boot.S? > > [...] > > What am I missing here? How could we possibly tell without seeing the code in question? Post the header and the assembler file, and the log text from the build. You can invoke the C preprocessor standalone via cpp. That way you will be able to pre-process the file without assembling and see the actual text that is being passed to the assembler assembled. That will probably shed some light onto the problem. http://gcc.gnu.org/onlinedocs/cpp/
Apologies. I turned on the -E option for GCC to check preprocessor output. If the boot assembly file is called startarm.s, CGG goes through all the .c files and creates .o files containing just the preprocessor output. For startarm.s it calls arm-elf-as and creates startarm.o output without any preprocessing as expected. However, when the boot assembly file is named startarm.S, GCC does not process it at all. There is no startarm.o produced. So there's my problem. I have not yet figured out the correct switch(es) to make GCC assemble a .S file.
Problem solved. Of course I should have mentioned that I'm using Eclipse/CDT for the build. Eclipse associates *.s files as assembly files, but has no association for *.S files. The fix is to associate *.S with "C Source File" in the File Types Preferences. Then it will pass it to GCC.
jdupre wrote: > Problem solved. Of course I should have mentioned that I'm using > Eclipse/CDT for the build. I am pretty sure I would not have spotted the problem even had you done so. I would have created a custom rule to run arm-elf-cpp and then arm-elf-as in sequence rather than rely on the gcc compiler driver.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.