Community
Participate
Working Groups
At the moment, default CDT project types (those in org.eclipse.cdt.managedbuilder.gnu.ui) plugin, use 'as' as assembler command. As result, input files with extension .S are not automatically preprocessed. I suggest to use the 'gcc' command, that can accept assembler sources just fine and will handle preprocessing of .S files.
That's a great point. We'll have to look at doing this.
Actually, it does not seem that CDT cares about what is in the toolchain when it comes to uppercase "s" files. We've declared our own toolchain that should handle both "s" and "S" files. When building a ".s" file our assembler is called as expected, but when building a ".S" file the output becomes: cc -E ../foo.S > ../foo.s
See also bug 103530. Letting GCC handled the ".S" files by declaring a content type (in Ganymede) does work.
> See also bug 103530. Even better, see bug 278026 for an explanation and possible fix.
Yes, CDT should use gcc for *.S files. But it doesn't stop there. CDT should also pass the symbols (-D switches) as well as -mcpu and -march options to gcc since they are passed on to the assembler by gcc. These flags decide which instructions are valid and which are not. Beside -march and -mcpu there are also switches like -mfloat-abi=soft have an effect on the .o file generated by the assembler. Each .o contains flags which ABI (endianness, FPU, float-ABI, etc.) they target and the linker checks for compatibility when linking. Also, CDT should call gcc for *.s files, since, even though they are not preprocessed, the options passed to gcc matter and gcc knows best what options to call the assembler with. Also, what's the status of this bug? Why is ASSIGNED since 2006, but not much has changes since then?
(In reply to Sven Köhler from comment #5) > Also, what's the status of this bug? Why is ASSIGNED since 2006, but not > much has changes since then? Nobody is working on it. You are welcome to contribute
