Since rev 7102 I have been unable to generate correct mcs51 banked images. In the resulting hex files, there are no extended linear address records. I've tried various revisions since then but I've always had to revert to 7100, which seems to work fine.
This report is based on tests on OS X Lion 64bit but I've observed the same problems on 32bit Ubuntu 11.x. This report uses rev 7100 and 7484 as good/bad examples but the same problem occurs with 7102 and various other revs in between.
I build SDCC from sources, configured with:
./configure --disable-gbz80-port --disable-z80-port --disable-ds390-port --disable-ds400-port --disable-pic14-port --disable-pic16-port --disable-hc08-port --disable-r2k-port --disable-z180-port --disable-sdcdb --disable-ucsim
Working revision:
SDCC : mcs51 3.1.1 #7100 (Mar 25 2012) (Mac OS X x86_64)
Recent bad revision:
SDCC : mcs51 3.1.4 #7484 (Mar 25 2012) (Mac OS X x86_64)
Attached a simple test case to reproduce it.
With 7100:
cexgo@cerberuss-MacBook-Pro:~/debug$ sdcc --model-huge --stack-auto --std-c99 --codeseg BANK3 -Wl-r -Wl-bBANK3=0x028000 -o foo.hex foo.c
output extended linear address record 0x2 0x0
output extended linear address record 0x0 0x2
cexgo@cerberuss-MacBook-Pro:~/debug$ srec_info foo.hex -intel
Format: Intel Hexadecimal (MCS-86)
srec_info: foo.hex: 4: warning: data records not in strictly ascending order
(expected >= 0x0079, got 0x0003)
Execution Start Address: 00000000
Data: 000000 - 00007C
028000 - 028002
With 7484 (and 7102 and…)
cexgo@cerberuss-MacBook-Pro:~/debug$ /Users/cexgo/sdcc/bin/sdcc --model-huge --stack-auto --std-c99 --codeseg BANK3 -Wl-r -Wl-bBANK3=0x028000 -o foo.hex foo.c
cexgo@cerberuss-MacBook-Pro:~/debug$ srec_info foo.hex -intel
Format: Intel Hexadecimal (MCS-86)
srec_info: foo.hex: 3: warning: data records not in strictly ascending order
(expected >= 0x0079, got 0x0003)
Data: 0000 - 007C
8000 - 8002
See the difference in the srec_info output for the two hex files. The second one does not list anything above 0x8000. There are not extended linear address records in this hex file.
foo.rel seems reasonable:
...
A BANK3 size 3 flags 20 addr 0
...
and I can't see anything wrong with the map file either, with BANK3 listed at the address where it's meant to be:
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
BANK3 00028000 00000003 = 3. bytes (REL,CON,CODE)
Value Global Global Defined In Module
----- -------------------------------- ------------------------
C: 00028000 _main foo
…
HOME = 0x0000
ISEG = 0x0000
BSEG = 0x0000
BANK3=0x028000
To reproduce
George,
Can you please test with SDCC #8716? I think it's fixed now.
Maarten
I'm trying with r8717 and the attached but I'm still stumbling.
$ make
mkdir -p build_r8717
/Users/cexgo/repos/sdcc/builds/r8717/bin/sdcc --std-c99 --model-huge --stack-auto --codeseg BANK3 -c foo.c -o build_r8717/foo.rel
/Users/cexgo/repos/sdcc/builds/r8717/bin/sdcc -Wl-r -Wl-bBANK3=0x038000 --std-c99 --model-huge --stack-auto -o build_r8717/foo.hex build_r8717/foo.rel
srec_info -disable-sequence-warnings build_r8717/foo.hex -intel
Format: Intel Hexadecimal (MCS-86)
Data: 0000 - 007A
8000 - 8002
Ok, thanks for testing.
Btw. You do realize that you can't place main() in a bank, right? The startup code knows nothing of banks. (I understand that this has nothing to do with the bug.)
Hi George,
Can you please try again with #8719? Last time I forgot I had several modifications in the assembler and linker too. And they were not quite right either. I hope it is fixed now.
Maarten
I tried a test build with 8721 and the resulting hex looks like what I'd expect it to look like. I won't be able to try on actual hardware for a couple of days but I can't think why it wouldn't work.
Many thanks for the efforts, Maarten!
Fixed in SDCC 3.3.1 #8719.