Assembler not consistent with pre-processor macros

DavidZemon

Computer #1 is Ubuntu 13.10 with PropGCC installed via SimpleIDE. propeller-elf-gcc -v returns version 1.0.0.2261
Computer #1 works perfectly.

Computer #2 is Windows 8.1 with PropGCC installed via SimpleIDE. propeller-elf-gcc -v returns version 1.0.0.2162
Computer #2 does not process "#include <file.h>" or various "#define THE_ANSWER 42"

Does anyone know why or how I can get around this? Compiling PropGCC from source is not a good solution to my overall goals.

jazzed

Hi,

Please post sample code and what is meant by "does not process".

DavidZemon

The code is spi_as.S (link) from the development branch of PropWare (link).

When I compile libPropWare_lmm.a and then view the map, I get numerous lines like below. BIT_0 is defined in line 51 of PropWare.h (link). PropWare.h is supposed to be included by line 31 of spi_as.S, but PropGCC seems to be ignoring the line as though it's a comment.

00000000         *UND*    00000000 BIT_0

Lines 35 through 54 of spi_as.S provide constants like "#define SPI_FUNC_SEND 0" but they are not being processed because they're showing up in the map like so:

00000000         *UND*    00000000 SPI_FUNC_SEND

By processed, I mean parsed and replaced with values throughout the file like the C preprocessor. It works great with PropGCC v1.0.0.2261 (I assume this is coming from a difference in PropGCC versions, not Windows vs Linux).

David Betz

SwimDude0614 wrote: »

Computer #1 is Linux 13.10 with PropGCC installed via SimpleIDE. propeller-elf-gcc -v returns version 1.0.0.2261
Computer #1 works perfectly.

Computer #2 is Windows 8.1 with PropGCC installed via SimpleIDE. propeller-elf-gcc -v returns version 1.0.0.2162
Computer #2 does not process "#include <file.h>" or various "#define THE_ANSWER 42"

Does anyone know why or how I can get around this? Compiling PropGCC from source is not a good solution to my overall goals.

Are you sure that the assembler file is named with a ".S" extension (uppercase "S") on the machine that doesn't work? The GNU assembler (gas) only runs the preprocessor on files ending with an uppercase "S".

DavidZemon

It's a Windows computer... so I have no idea. I'm mainly a Linux guy so I don't know exactly how the naming works here, and how gas reads the name. I know that in Linux, and what I see in Windows Explorer is a file named "spi_as.S" with an uppercase file extension.

Heater.

What is "Linux 13.10"?

The last unstable Linux release is 3.13-rc8.

DavidZemon

Sorry, that was dumb. I meant Ubuntu 13.10.

Heater.

Upper case vs lower case, \ vs / as a path separator, spaces in file and directory names.

Just guessing. I have no idea how well SimpleIDE handles these Windows quirks.

jazzed

Heater. wrote: »

Just guessing. I have no idea how well SimpleIDE handles these Windows quirks.

Because of QT, it converts everything to linux path separators and effectively encloses all arguments passed to the compiler in "" i.e. "some silly file.c".

If a SimpleIDE problem is suspected, use the command line tools and try to reproduce the issue. Get GNU make binaries here: http://gnuwin32.sourceforge.net/packages/make.htm ... I had to do this Thursday for a project, and it worked fine.

DavidZemon

I am using command line utils. I've documented my build process here.

I should add though, the above link points to the Doxygen docs. Within that page are two links to the source code on GitHub - if you follow those, they point to the master branch and I'm currently working on the development branch.

David Betz

SwimDude0614 wrote: »

It's a Windows computer... so I have no idea. I'm mainly a Linux guy so I don't know exactly how the naming works here, and how gas reads the name. I know that in Linux, and what I see in Windows Explorer is a file named "spi_as.S" with an uppercase file extension.

I believe that Eric Smith once told me that you can use ".sx" as a file extension instead of ".S" to get the preprocessor to run on operating systems that don't distinguish case. What I'm not sure of is if this behavior is built into GCC or if is part of the Makefile we use to build our libraries.

DavidZemon

I actually found (what I think to be) an even better fix. You can pass -x assembler-with-cpp as an option and it forces it to use the prepocessor. I already confirmed this works in Windows and am now just doing some cleanup and branch merging before pushing it to master. Thanks!

ersmith

David Betz wrote: »

Are you sure that the assembler file is named with a ".S" extension (uppercase "S") on the machine that doesn't work? The GNU assembler (gas) only runs the preprocessor on files ending with an uppercase "S".

And that's a problem on Windows, because Windows file systems are case insensitive. I suspect that is the root problem -- I think under Windows gcc (or Make, or SImpleIDE) can't distinguish between ".S" and ".s" files.

There are two work-arounds: add an explicit command line argument to gcc to invoke the preprocessor, or (easier) change the file extension to ".sx" instead of ".S". ".sx" means "assembler that needs pre-processing" (just like .S) but doesn't rely on case. Both solutions should work fine under Linux as well as Windows.

(Edited: I see David and SwimDude have already found these solutions!)

DavidZemon

Ha, yep. Thank you two both for the help. This is making me feel like PropWare is getting very close to obex ready! I think I started PropWare about a year ago and this is the first time it's been both Windows and Linux compatible.