#3610 Windows specific 32-bit sdar failure with modified CSEG

[Deqing Sun]

Hi I got a quite weird bug with windows build 14184. I was using SDCC for an Arduino port for MCS51 core and the chip need alignment of code for faster execution. So as a workaround. I add CSEG by 1 if the number is odd. It worked well before and also worked on Mac and Linux. But the windows compiler gave me "file format not recognized" error. I messed around for a while without getting a clue.

In the zip file are some of the compiled files.
If I add the o files to a new .a lib, All o files can be added to library successfully.
If I add the rel files to a new .a lib, the last genericPrintSerial0Float.c.rel will create the "file format not recognized" error. And the .a file will be corrupted. Any future adding file will give the same error.

Any suggestions?

[Deqing Sun]

Some update:
The sdcc of windows and mac created a slight difference .o file in one of the .c file. So I used the .o file generated from mac as a start point to test sdar in mac and windows.
Each .rel (adjusted CSEG only) is added to a library file, in each step, the .a file is backuped.

So until the testCore11.a in win and mac both look OK. but when the genericPrintSerial0.c.rel is added. The testCore12.a mac file is still OK. But the testCore12.a win file lost content.

The command I used was something like:

sdar rcs testCore.a genericPrintSerial0.c.rel

[Philipp Klaus Krause]

Could you post the exact sequence of commands you used?

P.S.: And maybe the resulting files when you use rcDs instead of rcs?

[Deqing Sun]

Here are the 2 files causing trouble. I was using snapshot build.14184
Command was like
sdar.exe rcs testCore11.a genericPrintSerial0.c.rel
I tried again on Mac, that was totally fine.
But on Windows, this command does not throw any error. And the .a file shrink from 160K to 6K. I think that is the moment it get corrupted as the text viewer can not see any instructions in that file anymore.
The rcDs does not help.

[Philipp Klaus Krause]

The D wasn't meant to help with the issue directly, but just to produce files that might be more helpful for our debugging (the D eliminates timestamps, to make the results reproducible).

[Deqing Sun]

Get it, I will try to compare the difference between the Mac and Win files with D flag later today when I get to the computer with the batch script.

[Deqing Sun]

Here is package with all files used. All command I used can be found in the batch script files.
The .a files are identical until it get corrupted in windows like

sdar.exe rcDs testCore.a genericPrintSerial0.c.rel

[Philipp Klaus Krause]

Thanks. Apparently the bug only affects the 32-bit sdar.exe, not the 64-bit one. I testes with a locally-built amd64 sdar.exe, the amd64 snapshot and the x86 snapshot, all using wine on my Debian GNU/Linux testing system.
The amd64 versions give me the result you see on macOS, the x86 version gives me the result you see on Windows.

P.S.: On the other hand, a native GNU/Linux x86 sdar apparently works fine.

P.P.S.: Can you confirm that for you, too, the bug only affects the 32-bit Windows sdar.exe, not the 64-bit one?

[Philipp Klaus Krause]

I also build an sdar.exe locally. 32-bit, but using a newer gcc and targeting Pentium Pro (i686). The farm uses an older gcc and targets Pentium (i586).
The sdar.exe build for Pentium Pro works fine for me.

P.S.: Maybe this is actually a bug in the old GCC used in the farm, and upgrading it would fix this issue for the i586 snapshots.

[Deqing Sun]

Yes sdcc-snapshot-x86_64-w64-mingw32-20230707-14184 works well for me.

[Philipp Klaus Krause]

I just tried with a current 32-bit Windows snapshot, and could not reproduce the issue. Looks like indeed this was an issue with an older GCC used to build Windows snapshots in the farm back when this issue was reported (AFAIK it has since been upgraded to GCC 11).

Could you check if this works for you now?