GCC problems.

[Mike Rigby]

Hi guys

I am compiling for the Renesas HD3048F 16-bit H8300H processor, using a PC running Windows 2000 Professional..
I am having problems installing GNUH8SX_v0401 20030719.  We are upgrading the compiler from an earlier release because we downloaded an operating system patch for the Sasser virus, and following the 'upgrade', the original compiler falls over with a stack error, so we cannot compile.

I have installed v0401 to run under the Renesas High Performance Embedded Workshop versio 3.0.06 (release 2), and I have also installed it so that it runs under the editing system Codewright 6.0 (v6.0c).

In both environments, I can compile my 'C' source and assemble my startup assembler file, and so far as I can tell, the object files are correct, and no problem.  The problem with both setups is linking, and the symptoms in each case are different

Under CodeWright:
--------------------------
I can set the linker to generate a binary output file, or an S-Record file (using the linker option --oformat srec or --oformat binary, and I do get either an S-Record file, or a pure binary file, as expected.  Unfortunately, the linked output is wrong.  The JSR absolute instruction is wrong.  It should be 5E xx xx xx (4 bytes total).  The linker is generating 5E xx xx xx xx (5 bytes) i.e. it is filling in the address portion using 4 byes instead of 3, so it is overwiting the first byte of the next instruction (the actual address filled in is correct).  This generates a 5 byte instruction which is invalid on a 16-bit processor.  The output is the same (content-wise) in either binary or S-record formats i.e. JSR is wrong.  If I do not include the --oformat option, I get S-Records.

Under HEW:
-----------------
I can select either S-record or default output format.  The actual format I get is the same in both cases - a binary format which I assume is default (when I select S-records, I still get binary). 

However, the output file correctly links the JSR instruction - it becomes 5E xx xx xx, which is correct (and the targer address is also correct).  Unfortunately, I cannot use this default format because it contains additional data at the beginning of the output file (and possibly within it).  I have no documentation to tell me the file format.

HEW is able to display both the operating environment used by the compiler / linker, and the command line.  With S-records selected, the command line appears to be:

Command Line :
h8300-elf-ld-wrapper.exe
-L "c:\program files\renesas\hew30\tools\kpit cummins\gnuh8sx-elf\v0401\h8300-elf\lib\gcc-lib\h8300-elf\3.4-GNUH8SX_v0401\h8300h" -L "c:\program files\renesas\hew30\tools\kpit cummins\gnuh8sx-elf\v0401\h8300-elf\h8300-elf\lib\h8300h" -o "C:\cyg_h8\DM990\Source\DM990_DX800\Debug\DM990_DX800.x" <S-Record> -Map "C:\cyg_h8\DM990\Source\DM990_DX800\Debug\DM990_DX800.map" -e _start -( -l "m" -l "c" -l "gcc" -)

At the point in the HEW environment where I select S-record output, HEWsays that it is going to use the option --oformat=srec (it lists the options in a box labelled Common Options).  The actual commad line contains the string <S-Record>.  If I selct default format in the environment, there is no --oformat entry in the Common Options box (the --oformat entry disappears), and the actual linker invocation line contains the string <Default> instead of <S-Record>.  Looking at the LD documentation, there is no mention of options in angle brackets - this would appear to be invalid.

When compiling under CodeWright, I have tried using exactly the same linker command line as used under HEW.  I have also tried setting all of the relevant environment variables to be the same.  Thus the environment appears to be the same, the command line appears to be the same, and I have checked that I am definitely calling the v401 version of the linker.

I can see nothing in the linker command line which will cause the output format to

I have also tried v0304, with the same results.

Questions:
--------------
1. Are you aware that the linker can link H8300H code and get it wrong?
2. Do you know how I can get round this?
3. Do you know why links correctly under HEW?
4. Do you know how I can usefully use the HEW output file?

I include the HEW output file (DM990_DX800.x), the Codewright output file (s), the listing (START.LST) from my startup file START.S,  the HEW map file (DM990_DX800.map), and the CodeWright map file (s.map).  The processor reset vector is 4 bytes at address 0, and in the Codewright file, the vector is at address 0 in the file.  it points to address 41B2.  At 41B2 in the CodeWright Srecord file, the S-Record output code is as follows:

S2140041B27A07000FFF0C6DF35E0000434E736DF33B
The above line is repeated, and split up, with comments:
S2140041B2              Srec type, line length, address       
7A07000FFF0C    mov.l   #_stack,sp
6DF3                    push.w r3
5E0000434E              jsr _tmp_flash (this is wrong - should be 5E00434E)
73                      should be 6D73          pop.w r3
6DF3                    push.w r3
3B                      checksum

I have now spent some 45hours on this at high cost, and extremely high levels of frustration.  If you cannot assist, the only option will be to revert to the original working compiler, and load it onto older machines, and use those for compiling.  I hope you can make some suggestions.

<<s>> <<start.lst>> <<DM990_DX800.x>> <<DM990_DX800.map>> <<S.MAP>>

s
Description: s

start.lst
Description: start.lst

DM990_DX800.x
Description: DM990_DX800.x

DM990_DX800.map
Description: DM990_DX800.map

S.MAP
Description: S.MAP