Re: GNU-Toolchain for Hitachi H8/300H Problems/Bugs?

["Kai Ruottu" <karuottu@freenet.hut.fi>]

Randall Loomis wrote:

> check out http://www.zanshinsys.com/linux-h8300
> There's a HOWTO there for building the H8/300 toolchain for linux
> using egcs-1.1, you should not use gcc-2.8.1

 Agreed, the gcc-2.8.1 includes quite a lot known bugs for H8/300, the egcs
releases have fixed quite a lot, but some still exist...

 So the available egcs-19990524 - 19990608 (or newer) snapshots, the gcc-2.95 
prereleases, can be still better. The latest H8/300-bug corrected in them,
which I'm aware of, is the following :

------- Forwarded Message Follows -------
From:          Self <karuottu>
To:            "Gütlein" <ralf.guetlein@rhein-main.netsurf.de>
Subject:       Re: gnuH8: BUG still there in egcs-1.1.2
Cc:            gnuh8@pcserv.demon.co.uk
Reply-to:      karuottu@freenet.hut.fi
Date:          Tue, 1 Jun 1999 19:49:58

"Gütlein" <ralf.guetlein@rhein-main.netsurf.de> wrote:

> Bug still there in GNU compiler version egcs-1-1-2
> ====================================
>
> I recently downloaded cross compiler binaries for win32 host from
> somewhere (can't remember the URL; had sth. to do with "LegOS").
>
> I realized that this version has no major changes in compiler output
> compared to 97r2 - even the bug I mentioned a few months ago is still
> "working" (joke ;-)
>
> The following source (useless and dangerous because the addresses 
> stored in static pointers are becoming invalid after return from bug() )
>
>  typedef unsigned char byte;
>
>  byte *d, *e, *f;
>
>  void bug (byte a, byte b, byte c)
>  {
>     d = &a;
>     e = &b;
>     f = &c;
>  }
>
> compiled with
>
> cc1 bug.c -O1
>
> results in the following assembler output:
>
>  _bug:
>        push	r6
>        mov.w	r7,r6
>        subs	#2,sp
>        subs	#2,sp
>        mov.w	r0,@(-2,r6)      //<-- the error is here!!!
>        mov.b	r2l,@(-3,r6)
>        mov.w	r6,r2
>        subs #1,r2
>        mov.w	r2,@_d
>        mov.w	r6,r2
>        subs #2,r2
>        mov.w	r2,@_e
>        mov.w	r6,r2
>        subs #2,r2
>        subs #1,r2
>        mov.w	r2,@_f
>        adds	#2,sp
>        adds	#2,sp
>        pop	r6
>        rts
>
> The compiler generates 
>   mov.w r0,@(-2,r6)  //error
> instead of
>   mov.b r0l,@(-1,r6) //correct sequence
>   mov.b r1l,@(-2,r6)
> or instead of
>   mov.b r1l,r0h        //also correct
>   mov.w r0,@(-2,r6)
>
> causing that parameter "b" is discarded, and an undefined value (the
> unknown value of r0h) is used instead.

The gcc-2.95 prerelease (egcs-19990524) gave:

_bug:
 push	r6
 mov.w	r7,r6
 subs	#2,sp
 subs	#2,sp
 mov.b	r0l,@(-1,r6)
 mov.b	r1l,@(-2,r6)
 mov.b	r2l,@(-3,r6)
 mov.w	r6,r2
 subs #1,r2
 mov.w	r2,@_d
 subs #1,r2
 mov.w	r2,@_e
 subs #1,r2
 mov.w	r2,@_f
 adds	#2,sp
 adds	#2,sp
 pop	r6
 rts

So somebody has done something to it already...

> Is there anybody with enough knowledge and practice to suggest (or
> implement) a bugfix? I would be glad to play a "beta tester" for him.

Please track the site/page:
    www.nettilinja.fi/~ankosken/embtools.htm
for a possible update release 'Really Soon Now'...

I must check the Win32 cygwin/mingw host support in the 'gcc-2.95'
sources first. (I built a cross-compiler for Linux and djgpp-2.02 hosts
already, but no Win32-hosted one has yet been built...)

Cheers, Kai

------- Forwarded Message Ends -------

 The Win32/mingw32-hosted gcc-2.95 toolset has been there for some time, but 
the 'Cygnus relative-paths' fixes weren't installed in the original sources,
so it doesn't find the 'as' and 'ld' from the '<prefix>/<target>/bin' 
directory, if used from another disk, although the GCC_EXEC_PREFIX has been set 
correctly. Anyhow noboby has complained about this 'known bug' in the 
H8/300-snapshot toolset yet.

 The H8/300 support hasn't changed since egcs-19990524. But I have now 
installed the 'relative path' fixes to the 19990602 sources (and also patched 
the sources to 19990608). So getting gcc-2.95-based Win32-hosted things easily 
when the gcc-2.95 release is 'official', should be quite easy...

 For the Linux host, there aren't any problems of this kind... 

 I strongly suggest building the H8/300 compiler from the current gcc-2.95 
prerelease and then trying to compile newlib with it...

Cheers, Kai
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.