Cannot use assembly files in MCS51 platform due to core issue

[maxgerhardt]

What kind of issue is this?

• [X ] PlatformIO Core.
  If you’ve found a bug, please provide an information below.

You can erase any parts of this template not applicable to your Issue.

---

Configuration

Operating system: Windows 10 x64

PlatformIO Version (platformio --version): PlatformIO Core, version 5.2.0a3

Description of problem

Per https://community.platformio.org/t/mcs51-assembler-programming/20410.

When attempting to write an assembler program for a MCS51 device on Windows by creating a src/blink.s file, the following error occurrs

Building in release mode
sdcc -DF_CPU=11059200 -DHEAP_SIZE=64 -DPLATFORMIO=50200 -Iinclude -Isrc -c -o .pio\build\stc15f204ea\src\blinky.rel src\blinky.s
at 1: error 119: don't know what to do with file 'src\blinky.s'. file extension unsupported
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.8.4 #10766 (MINGW64)

Suddenly it wants to use sdcc, the C compiler, for the .s file, but in the special case of SDCC, it does not know how to handle assembly files.

The platform code

https://github.com/platformio/platform-intel_mcs51/blob/c52ea3a706e540df65bdc6a0caf64f1eefeb8ac9/builder/main.py#L56-L60

sets the correct AS="sdas8051" directive, however the code in

platformio-core/platformio/builder/tools/platformio.py

Lines 115 to 117 in 73d4f10

	# fix ASM handling under non case-sensitive OS
	if not Util.case_sensitive_suffixes(".s", ".S"):
	env.Replace(AS="$CC", ASCOM="$ASPPCOM")

overwrites the assembler on non-case-sensitive operating systems to SDCC, thus causing the issue.

Steps to Reproduce

1. Create a new project for the stc15f204ea board
2. Add a blink.s file with empty content
3. Hit "Build"

Actual Results

sdcc -DF_CPU=11059200 -DHEAP_SIZE=64 -DPLATFORMIO=50200 -Iinclude -Isrc -c -o .pio\build\stc15f204ea\src\blinky.rel src\blinky.s
at 1: error 119: don't know what to do with file 'src\blinky.s'. file extension unsupported

Expected Results

It uses sdas8051 correctly, as it actually does on Llinux.

Building in release mode
sdas8051 -o .pio/build/stc15f204ea/src/blinky.rel src/blinky.s
[..]

(note: the assembler flags are still wrong per linked issue, but that's a different issue)

If problems with PlatformIO Build System:

The content of platformio.ini:

[env:stc15f204ea]
platform = intel_mcs51
board = stc15f204ea

Source file to reproduce issue:

Additional info

On Linux systems this issue does not occur

Building in release mode
sdas8051 -o .pio/build/stc15f204ea/src/blinky.rel src/blinky.s

But final linking fails due to multiple other issues which will be filed separately in the MCS51 platform (missing -l assembler flag, etc.).

[maxgerhardt]

Addendum: This issue also applies to platform-ststm8 if someone tries to actually use the sdasstm8 assembler with assembly files.

https://github.com/platformio/platform-ststm8/blob/712f391f99a6b767fe7f1183fdb2b7d4d239b549/builder/main.py#L26-L29

Addendum 2: The current behavior is okay for all GCC toolchains, it's just wrong for the SDCC toolchain.

[ivankravets]

Thanks for the report! It is a very interesting issue, mainly related to the SCons. See https://github.com/SCons/scons/blob/master/SCons/Tool/asm.py#L44
As you can see, a default ASM tool declares ".s" and ".S" extensions on Windows (non-case-sensitive) for ASCOM. This is classic behavior for native compilers but not for GCC. The f63b2f7 fixes this situation.

Nevertheless, we found a historical bug in ALL dev-platforms where we overwrite ASFLAGS with the preprocessor's data instead of ASPPFLAGS. We will fix it soon.

[positron96]

My platformio just upgraded to 6.0.1 and for some reason, the build for STM32 started to fail with this message:

Compiling .pio\build\board\src\cubemx\startup_stm32f407xx.o
arm-none-eabi-as: unrecognized option `-x'

Apparently, my platformio.ini file has always contained line

src_filter =     
+<cubemx/startup_stm32f407xx.s>

and it has always worked fine on Windows.

When I changed the line to uppercase ".S", the build started to work fine.

Does the fixing of this issue mean that, from now on, all projects that referenced ".s" files and worked before need to be changed and files renamed to uppercase?

[ivankravets]

Yes, it was a historical bug in SCons on Windows, and we decided to fix it on our side. See http://draskovblog.blogspot.com/2008/12/gcc-differences-between-s-and-s.html

[positron96]

Ok, thanks for the link.
Am I right that .S files are passed to gcc (with -x) option, and .s files are passed to as (also with -x option) and the latter complains about -x option? Then there is a problem for those who have rightful .s files (to be passed directly to as).

Also, the compilation database shows arm-none-eabi-as.exe for both .s and .S, despite calling different programs in reality. Is this a bug?

[ivankravets]

Yes, .s and .S are assembly files and as.exe is used. The only flags are different. You can check this with pio run -t envdump. Please search for ASCOM.