#3303 [Windows] [STM8] Wrong paths in the generated elf file

[BOBAH]

I have been working with STM8 for a long time in SI, so I decided to try to go with IAR on Vscode + Platformio (SDCC + SPL + GDB), because from my point of view, at least simple and convenient.
But I ran into one unpleasant feature - when using libraries, SDCC generates an incorrect .elf file.

The analysis led me to a ticket [#3200] that describes the same behavior that I encountered.
But my analysis showed that this has to do with the Windows-paths of the source files, and not the number of these files in the project nor their accompanying warnings.
For this reason, I opened a new ticket.

The main problem is that file paths are formatted. Perhaps for Linux (I'm not an expert) - this is a normal situation when \n, \a, \b etc are replaced with the corresponding symbol codes, but for Windows this is not suitable .
for example platformio places libraries at:
C:\Users\noname\.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\
but the elf file gets a formatted string:
C:\Users oname\.platformio\packages♀ramework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\

similarly we can find another strings like:
C:\Users oname\.platformio\packages○oolchain-sdcc◘in\..\include\stm8

local project files are not bypassed either, if they names starts from "taboo symbols":
src♀ont_arial.c

[Philipp Klaus Krause]

I see this posted in the patch tracker, but no patch attached to the post.
Is there a patch coming? If not, I'll move the ticket to the bug tracker.

[BOBAH]

Sorry
I'm sorry, this is my first time on sourceforge and I haven't figured it out yet
I tried to find a solution myself, but I'm not sure if I can test the fix on all platforms
Please carry this over to errors.
thx a lot

[Benedikt Freisen]

Can you provide a minimal example that can be used to reproduce the issue?

[BOBAH]

The minimal example is spl-blink for stm8sblue board from the platformio plugin for VSCode, with additional build options --out-fmt-elf --debug.

But this path is too long for a developer to debugging.
So, I attached fully compiled with ready to burn binaries.

Preparation: extract archive and set current directory 220107-114753-spl-blink

Linking: to link "as is" the elf file, just call !_linker.bat, but update the SDCC_DIR to your developing SDCC path
Then you may find target elf-file in: .pio\build\stm8s003f3\firmware.elf

Verification: The simplest way to check the correctness of paths - simple open this file in the notepad and check strings
if all ok - you should see strings like C:\Users\User\.platformio\packages\tolchain-sdcc\bin\..\include\stm8
but now you may see only C:\Users\User\.platformio\packages oolchain-sdccin\..\include\stm8 (see already attached firmware.elf)

Debugging: If I'm correct, the issue in the sdldstm8.exe file, so you may need to debug it. I prepared another !_linker_stm32.bat file (with .pio\build\stm8s003f3\firmware.lk and copy of original stm8.lib library).
You may use those settings and filed in your IDE while debugging.

Final verification:
It will be great if you will be able to build, burn and start debugging this firmware using VSCode + Platformio + STlink-v2 under Windows.

I hope I managed to make it as easy as possible to prepare the environment for debugging.

[Philipp Klaus Krause]

Ticket moved from /p/sdcc/patches/410/

Can't be converted:

• _milestone:

[Benedikt Freisen]

The garbled file names are in section .debug_line and section .debug_info of the elf file.
I believe that the former is generated by the function dwWriteLineNumbers in SDCCdwarf2.c.
The line dwWriteString (srcfile->name, NULL); in there generates an !ascii entry in the output. I do not see anything that could garble C escape sequences in SDCC itself, because the string ultimately winds up in vsprintf, so I assume that the string constant parsing in SDAS does it. This would at lest make sense.

Addendum:

The definition of dwWriteString contains the following line, so I guess we should fix it in there.

/* FIXME: need to safely handle nonalphanumeric data in string */

An example line from main.asm:

.ascii "C:\Users\User\.platformio\packages\toolchain-sdcc\bin\..\include\stm8"

I can see how this could cause problems.

[BOBAH]

You right - the .rst files already have wrong section .debug_line and section .debug_info

      000018 43 3A 5C 55 73 65 72   865     .ascii "C:\Users\User\.platformio\packages\toolchain-sdcc\bin\..\include\stm8"
             73 5C 55 73 65 72 5C
             2E 70 6C 61 74 66 6F
             72 6D 69 6F 5C 70 61
             63 6B 61 67 65 73 09
             6F 6F 6C 63 68 61 69
             6E 2D 73 64 63 63 08
             69 6E 5C 2E 2E 5C 69
             6E 63 6C 75 64 65 5C
             73 74 6D 38
      00005B 00                     866     .db 0
      00005C 43 3A 5C 55 73 65 72   867     .ascii "C:\Users\User\.platformio\packages\toolchain-sdcc\bin\..\include"
             73 5C 55 73 65 72 5C
             2E 70 6C 61 74 66 6F
             72 6D 69 6F 5C 70 61
             63 6B 61 67 65 73 09
             6F 6F 6C 63 68 61 69
             6E 2D 73 64 63 63 08
             69 6E 5C 2E 2E 5C 69
             6E 63 6C 75 64 65
      00009A 00                     868     .db 0
      00009B 00                     869     .db 0
      00009C 43 3A 5C 55 73 65 72   870     .ascii "C:\Users\User\.platformio\packages\framework-ststm8spl\Libraries\STM8S_StdPeriph_Driver\src\stm8s_gpio.c"
             73 5C 55 73 65 72 5C
             2E 70 6C 61 74 66 6F
             72 6D 69 6F 5C 70 61
             63 6B 61 67 65 73 0C
             72 61 6D 65 77 6F 72
             6B 2D 73 74 73 74 6D
             38 73 70 6C 5C 4C 69
             62 72 61 72 69 65 73
             5C 53 54 4D 38 53 5F
             53 74 64 50 65 72 69
             70 68 5F 44 72 69 76
             65 72 5C 73 72 63 5C
             73 74 6D 38 73 5F 67
             70 69 6F 2E 63

And the issue in the compiler, not in linker as I assumed before

[Benedikt Freisen]

Maybe something like this will do the trick?

(Warning: This patch is completely untested. I don't have a Windows machine handy.)

[Philipp Klaus Krause]

As far as I understand, the problem was stuff like \n in paths. You should be able to test that on GNU/Linux. \n can be part of a valid filename there.

[BOBAH]

This is the first thing that came to my mind and I wanted to check before posting a ticket.
And I tried to build the sdcc.sln. Unfortunately the VS solution is old and don't generate files like sdldstm8.exe. And it was the main reason to create bug-ticket.

I agree with @spth - the file names may contain \n symbol, but the sequence of characters "\n" should not be converted to single character "\x0D".

The attached *.rst already contains some necessary examples (like \t \b \f) and you probably may try to link (by converting .bat to .sh files) .rst-files under Linux/OSX.

Perhaps the problem may turn out to be much deeper - probably .rst files may be corrupted if they contain files with names/paths containing non-printable characters. By the way, the most of compilers have strong restrictions for names - not only "printable characters", but some for ANSI only.

[BOBAH]

This (linking .rel to .elf) will not fix the issue, because the .rel already corrupted.
So, as wrote @roybaer, should be fixed compiler.
Unfortunately I cannot build full staff of SDCC for Windows (in Visual Studio) by myself to check his patch.

[BOBAH]

I spent 3 days, but I could not prepare at least some working environment for the build binaries for Windows.

• the VS solution/projects is old and don't build full staff of executable files
• Cygwin under Windows build all executable, but they provide wrong application path (always say /usr/bin/) and cannot find other files (executable and headers+libs), so build always left with "file not found" error
• platform-specific code refers to _WIN32 (and WIN32) defines that related to VS but not Cygwin (__CYGWIN__), but if add all necessary defines (about 5pcs), the liking failed with errors - not found _vsnprintf and some funcs from Win32API
• trying to prepare cross building environment under Linux by instructions is also failed - mingw32 deprecated and should be used mingw64, but it failed at configuration stage, because boost stops support of cross building and cannot be found

I have some ideas how to improve the SDCC (for example: remove dead functions at link time), but due to insurmountable obstacles consisting of a "forest of crutches", I just cannot start checking my ideas.

So sad with this project, that I want to go back to IAR, COSMIC or write a STM8-backend for LLVM myself.

[Benedikt Freisen]

Truth be told, if using a Linux system is an option you have, doing so is by far the easiest route to success as far as SDCC development is concerned.
Actually, I do not even know whether any active project member does SDCC development in Windows.
As Philipp pointed out, my patch can probably be tested with funny file names in Linux, because a Linux file name is allowed contain backslashes. Unfortunately, I have not had time to do it yet.

Off topic / regarding cross compiling: Do you know the MXE environment?
I have never used it with SDCC, but cross-compiling a few smaller programs was pleasantly painless.

[Philipp Klaus Krause]

I mostly use Debian GNU/Linux (though I also once in a while use OpenBSD or FreeBSD). Last time I used SDCC on Windows (years ago), I used Cygwin. That worked fine for me (but I used SDCC from within Cygwin, calling it from Makefiles, like I would in GNU/Linux).

It should be possible to build SDCC via the Microsoft Visual Studio. In fact, the language dialect in which SDCC is written was chosen to make this possible: https://sourceforge.net/p/sdcc/wiki/Language%20dialects%20used%20in%20SDCC/
If there are issues, they should be fixed. AFAIR, @maartenbrock used to have a look at such issues years ago.

Have you tried doing the snapshot build process locally? https://sourceforge.net/p/sdcc/wiki/HOWTO%20Make%20Snapshot%20Builds%20on%20the%20Developer%20Machine/ documents it. AFAIK, there should be a configuration (hostname.mk) for the windows builds as used in the compile farm, too.

[Erik Petrich]

The compiler farm cross compiles the Windows snapshots from Linux,, so this would not necessarily be a good approach for building sdcc from within Windows itself. Would be much easier just to fix the problem (escape the backslashes or don't use the .ascii pseudo op) and just wait for a new snapshot.

[Maarten Brock]

Years ago I used to use MSVC to build and debug SDCC. But I must admit that lately I don't find much time for this project. So, I'm sure the msvc solution is far behind.

But since this problem seems present in our GCC cross-compiled binaries, it is not related to MSVC.

[BOBAH]

Thanks all for responses,

@roybaer, this project is used not only under Linux, but also in other OSs that can start Platformio and / or VSCode + Platformio-plugin as well as Arduino. If you look from this point of view, then this project has chances to be in demand in wide circles (and not only in the context of STM8, which surpasses AVR in characteristics and price, and at the same time is as close to electrical characteristics as possible). But there is one drawback: SDCC is pure-C, while Arduino-like projects are C++.
Relative to MXE - it also uses Linux (Unix-like OSes) with MinGW. And because the SDCC requires Boost during building, compilation (i.e. even configuration) will fail due to leak of Boost for target OS (i.e. leak of cross-compiled Boost for Windows)

@spth, I agreed, few years ago, mingw was mingw32 and Boost has support of cross compilation for mingw. But it was few years ago.
Regarding building on MS VS - yes, it possible, I even can got few workable files, but not full staff of binaries. VS projects required that developer must add to the project file (.vcxproj) all used files - it cannot use *.c mask ;)
VS may build, launch and debug cross-compilation projects, like for Android, OSx, Linux, some embedded (like ARM), supported few build system, like CMake. But not gnu-make.
It means, if you'd like to use MSVC, you should create MSVC project and highlight all necessary files name-by-name. And because nobody didn't update all .vcxproj (and add some new) during long time, so VS projects are outdated (or as I wrote "old").
Regarding "snapshot build process " as well as "hostname.mk", again - configuration cannot find Boost, because it stop support of cross build some time ago.

[BOBAH]

It took a long time, but I managed to overcome all obstacles :)

• First of all, I was able to compile full set of files SDCC under Windows using Cygwin with latest cygwin-gcc, Boost, C-headers and C-libs
• And I able to debug all executable files as well as use cool IDE - VScode for developments
• Unfortunately I am forced to use Cygwin build for target instead of MinGW, because some of builds requires wait function for execution of sub processes, which is not supported by mingw
• The installation of Cygwin is not mandatory (similar to MinGW) - just copy some of .dll files to the directory where placed SDCC executable files
• As I wrote before, in this case, Cygwin will return realpath() (as well as argv[0]) to /usr/bin/ folder. But it's not a problem, because it's "virtual path" (similar to /cygdrive/c/ and so). When application tried open or execute files, cygwinXXX.dlls convert this path to actual native path
• The application that cannot be found during launching sub-processes (like sdcpp from sdcc) was ... sh.exe (i.e. bash!!! wtf!). So, sh.exe also should be copied to the folder, if you try to make portable bundle.
• Next, Windows can handle C:\Windows\bla-bla\ as well C:/Windows/bla-bla/ and even c://winDoWs\\bLA-bla/, so we may preserve UNIX-like path inside application (i.e. #ifdef _WIN32 ... is useless for Cygwin in the most of cases)
• Applications, that used generated files (like gdb) also correctly handles paths
• So, to fix this issue, the paths from command line should be canonized to UNIX paths
• Also, for Windows SDCC may be compiled with sdccconf_h_dir_separator="/" argument without any issues

The final configuration of SDCC project under Windows and Cygwin is:

./configure -C \
--prefix="/sdcc" \
--datarootdir="/sdcc" \
docdir="\${datarootdir}/doc" \
include_dir_suffix="include" \
non_free_include_dir_suffix="non-free/include" \
lib_dir_suffix="lib" \
non_free_lib_dir_suffix="non-free/lib" \
sdccconf_h_dir_separator="/" \
CC="x86_64-pc-cygwin-gcc" \
CXX="x86_64-pc-cygwin-g++" \
CFLAGS="-mwin32" \
CXXFLAGS="-mwin32" \

And do not forget to apply the attached patch.
That mostly exclude Cygwin from the Native Win32 checks like

-#ifdef _WIN32
+#if defined(_WIN32) && !defined(__CYGWIN__)

This fix will build .asm files with the unix-like paths:

    .area .debug_line (NOLOAD)
    .dw 0,Ldebug_line_end-Ldebug_line_start
Ldebug_line_start:
...
    .ascii "/usr/bin/../include/stm8"
    .db 0
    .ascii "/sdcc/include/stm8"
    .db 0
    .ascii "/usr/bin/../include"
    .db 0
    .ascii "/sdcc/include"
    .db 0
    .db 0
    .ascii "C:/Users/User/.platformio/packages/framework-ststm8spl/Libraries/STM8S_StdPeriph_Driver/src/stm8s_gpio.c"
    .db 0
    .uleb128    0
...

Conclusion: The bug may be considered fixed for Windows (to some extent, because used Windows native handling of / as well as \)

[BOBAH]

https://sourceforge.net/p/sdcc/bugs/3303/#6824
remove dead functions at link time

Yes! I did it!
But for STM8 and as proof of concept

The results are the following, where "original" SDCC is 4.1.0 #12072 (MINGW64):

"Hello word!" from the box:

• original 667 bytes
• my 529 bytes

Stripping results:

  1. LOAD   GPIO_Init                                - 218 bytes
  2. LOAD   GPIO_WriteReverse                        -   9 bytes
  3. LOAD   ___str_0                                 - 105 bytes
  4. LOAD   Delay                                    -   4 bytes
  5. LOAD   main                                     -  26 bytes
  6. LOAD   assert_failed                            -   7 bytes
  7. LOAD   TRAP_IRQHandler                          -   1 bytes
  8. LOAD   TLI_IRQHandler                           -   1 bytes
  9. LOAD   AWU_IRQHandler                           -   1 bytes
 10. LOAD   CLK_IRQHandler                           -   1 bytes
 11. LOAD   EXTI_PORTA_IRQHandler                    -   1 bytes
 12. LOAD   EXTI_PORTB_IRQHandler                    -   1 bytes
 13. LOAD   EXTI_PORTC_IRQHandler                    -   1 bytes
 14. LOAD   EXTI_PORTD_IRQHandler                    -   1 bytes
 15. LOAD   EXTI_PORTE_IRQHandler                    -   1 bytes
 16. LOAD   SPI_IRQHandler                           -   1 bytes
 17. LOAD   TIM1_UPD_OVF_TRG_BRK_IRQHandler          -   1 bytes
 18. LOAD   TIM1_CAP_COM_IRQHandler                  -   1 bytes
 19. LOAD   TIM2_UPD_OVF_BRK_IRQHandler              -   1 bytes
 20. LOAD   TIM2_CAP_COM_IRQHandler                  -   1 bytes
 21. LOAD   UART1_TX_IRQHandler                      -   1 bytes
 22. LOAD   UART1_RX_IRQHandler                      -   1 bytes
 23. LOAD   I2C_IRQHandler                           -   1 bytes
 24. LOAD   ADC1_IRQHandler                          -   1 bytes
 25. LOAD   TIM4_UPD_OVF_IRQHandler                  -   1 bytes
 26. LOAD   EEPROM_EEC_IRQHandler                    -   1 bytes
  1. UNLOAD GPIO_DeInit                              -  18 bytes
  2. UNLOAD GPIO_Write                               -   2 bytes
  3. UNLOAD GPIO_WriteHigh                           -   9 bytes
  4. UNLOAD GPIO_WriteLow                            -  12 bytes
  5. UNLOAD GPIO_ReadOutputData                      -   2 bytes
  6. UNLOAD GPIO_ReadInputData                       -   3 bytes
  7. UNLOAD GPIO_ReadInputPin                        -  10 bytes
  8. UNLOAD GPIO_ExternalPullUpConfig                -  71 bytes
Stripping results: processed 34; loaded 26 (389 B); unloaded 8 (127 B)

**With small optimizations (just add static inline before all included functions)
**

• original 672 bytes
• my 192 bytes

Stripping results:
  1. LOAD   main                                     -  32 bytes
  2. LOAD   TRAP_IRQHandler                          -   1 bytes
  3. LOAD   TLI_IRQHandler                           -   1 bytes
  4. LOAD   AWU_IRQHandler                           -   1 bytes
  5. LOAD   CLK_IRQHandler                           -   1 bytes
  6. LOAD   EXTI_PORTA_IRQHandler                    -   1 bytes
  7. LOAD   EXTI_PORTB_IRQHandler                    -   1 bytes
  8. LOAD   EXTI_PORTC_IRQHandler                    -   1 bytes
  9. LOAD   EXTI_PORTD_IRQHandler                    -   1 bytes
 10. LOAD   EXTI_PORTE_IRQHandler                    -   1 bytes
 11. LOAD   SPI_IRQHandler                           -   1 bytes
 12. LOAD   TIM1_UPD_OVF_TRG_BRK_IRQHandler          -   1 bytes
 13. LOAD   TIM1_CAP_COM_IRQHandler                  -   1 bytes
 14. LOAD   TIM2_UPD_OVF_BRK_IRQHandler              -   1 bytes
 15. LOAD   TIM2_CAP_COM_IRQHandler                  -   1 bytes
 16. LOAD   UART1_TX_IRQHandler                      -   1 bytes
 17. LOAD   UART1_RX_IRQHandler                      -   1 bytes
 18. LOAD   I2C_IRQHandler                           -   1 bytes
 19. LOAD   ADC1_IRQHandler                          -   1 bytes
 20. LOAD   TIM4_UPD_OVF_IRQHandler                  -   1 bytes
 21. LOAD   EEPROM_EEC_IRQHandler                    -   1 bytes
  1. UNLOAD GPIO_DeInit                              -  18 bytes
  2. UNLOAD GPIO_Init                                - 218 bytes
  3. UNLOAD GPIO_Write                               -   2 bytes
  4. UNLOAD GPIO_WriteHigh                           -   9 bytes
  5. UNLOAD GPIO_WriteLow                            -  12 bytes
  6. UNLOAD GPIO_WriteReverse                        -   9 bytes
  7. UNLOAD GPIO_ReadOutputData                      -   2 bytes
  8. UNLOAD GPIO_ReadInputData                       -   3 bytes
  9. UNLOAD GPIO_ReadInputPin                        -  10 bytes
 10. UNLOAD GPIO_ExternalPullUpConfig                -  71 bytes
 11. UNLOAD Delay                                    -   4 bytes
 12. UNLOAD assert_failed                            -   7 bytes
 13. UNLOAD ___str_0                                 - 112 bytes
Stripping results: processed 34; loaded 21 (52 B); unloaded 13 (477 B)

PS:

1. in the original SDCC, the inlined variant increased the size of the code because it made dead functions
2. the sting___str_0 is parameter (path to the source file) of assert_failed, and both of then (___str_0 with assert_failed) were stripped because SDCC statically check the code and find it as unused
3. the tricks that I used, are not related to STM8 only, they are generic for any asm+link bundle
4. the final main code, where all functions are inline:

void main(void)
{
  /* Initialize I/Os in Output Mode */
  GPIO_Init(LED_GPIO_PORT, (GPIO_Pin_TypeDef)LED_GPIO_PINS, GPIO_MODE_OUT_PP_LOW_FAST);

  while (1)
  {
    /* Toggles LEDs */
    GPIO_WriteReverse(LED_GPIO_PORT, (GPIO_Pin_TypeDef)LED_GPIO_PINS);
    Delay(0xFFFF);
  }
}

took the form:

                                    471 ;   src/main.c: 88: void main(void)
      00808C                        472 _main:
                                    473 ;   /inc/../src/stm8s_gpio.c: 82: GPIOx->CR2 &= (uint8_t)(~(GPIO_Pin));
      00808C 72 1B 50 09      [ 1]  474     bres    0x5009, #5
                                    475 ;   /inc/../src/stm8s_gpio.c: 96: GPIOx->ODR &= (uint8_t)(~(GPIO_Pin));
      008090 72 1B 50 05      [ 1]  476     bres    0x5005, #5
                                    477 ;   /inc/../src/stm8s_gpio.c: 99: GPIOx->DDR |= (uint8_t)GPIO_Pin;
      008094 72 1A 50 07      [ 1]  478     bset    0x5007, #5
                                    479 ;   /inc/../src/stm8s_gpio.c: 113: GPIOx->CR1 |= (uint8_t)GPIO_Pin;
      008098 72 1A 50 08      [ 1]  480     bset    0x5008, #5
                                    481 ;   /inc/../src/stm8s_gpio.c: 126: GPIOx->CR2 |= (uint8_t)GPIO_Pin;
      00809C 72 1A 50 09      [ 1]  482     bset    0x5009, #5
                                    483 ;   src/main.c: 94: while (1)
      0080A0                        484 00102$:
                                    485 ;   /inc/../src/stm8s_gpio.c: 187: GPIOx->ODR ^= (uint8_t)PortPins;
      0080A0 90 1A 50 05      [ 1]  486     bcpl    0x5005, #5
                                    487 ;   src/main.c: 74: do
      0080A4 5F               [ 1]  488     clrw    x
      0080A5 5A               [ 2]  489     decw    x
      0080A6                        490 00118$:
                                    491 ;   src/main.c: 76: } while (--nCount);
      0080A6 5A               [ 2]  492     decw        x
      0080A7 26 FD            [ 1]  493     jrne    00118$
                                    494 ;   src/main.c: 98: Delay(0xFFFF);
      0080A9 20 F5            [ 2]  495     jra 00102$
                                    496 ;   src/main.c: 101: }
      0080AB 81               [ 4]  497     ret

The results are looks great!
Of course, most likely it would be so if this message was in any way related to this topic as I started.

Sorry for offtop

[Benedikt Freisen]

I added string escaping to dwWriteString in [r12964], because it was evidently missing, anyway.
There is a high likelihood that it fixes this bug. Please retest.