[linuxsh-dev] gcc problems?

[Bryan R. <br...@ix...>]

Hello linuxsh-dev,

After some more debugging I believe that gcc is producing very odd
assembly output for the sh-ipl stub, which may explain why it is doing
extremely strange things with string handling. Since I have followed all
the directions to the letter, I am quite confused as to what is going on
here... So let me spell out exactly what I've done, and maybe somebody
will be able to repeat my steps or help me get this stuff running.

binutils: I am using
ftp://ftp.m17n.org/pub/linux-sh/binutils-000218.tar.bz2 with
ftp://ftp.m17n.org/pub/linux-sh/bimutils-000218-000519.diff.gz applied
as a patch.
Built exactly according to instructions on
http://linuxsh.sourceforge.net/docs/building-source.php3

gcc: I am using latest gcc-core cvs, checked out around 12:00 PST today.
Built exactly according to instructions above. I have also worked with
older cvs versions from last week.

(In addition to the binutils and gcc used above, I have also tried
everything with the .debs on m17n.org with exactly the same problem).

sh-ipl: I started with sh-ipl+g-2000-08-16.tar.gz using the sesh4
config, then modified the machine/.mem file for my system. I also
modified the config (.h/.mk) slightly to use SCI. Then I changed the
init_bsc routine to correct the frequency control registers for my
system (6:3:1.5) and sh-sci.c to correct the UART multipliers. Even when
those are the only changes I've made, I get a bad sh-stub.bin.
Unfortunately I cannot test one of the precompiled srecs or existing
configurations since I do not have access to any of the supported
boards. But others are working with custom hardware without these
problems...

When using that slightly modified sh-stub, the system comes up with the
menu system and warranty/license viewing works fine. When I enter gdb
stub I get "$#00" (null packet) output to the terminal. In fact, this
null packet is all that is ever output regardless of what I send to it,
although getpacket is apparently evaluating checksums properly.

The problems appear with string handling--getpacket is not inputing
strings correctly, and the putpacket output is always empty. As I
mentioned before, if I change the order in which bytes in the array are
set, I can get the first packet (S05) to output correctly. For example,

  outbuff[1] = highhex(sigval);
  outbuff[0] = 'S';
  outbuff[2] = lowhex(sigval);
  outbuff[3] = 0;

will send a valid string to the terminal when putpacket(outbuff) is
called. However,

  outbuff[0] = 'S';
  outbuff[1] = highhex(sigval); 
  outbuff[2] = lowhex(sigval);
  outbuff[3] = 0;

results in a null packet being output. Needless to say this makes
absolutely no sense. I ran objdump on the elf output, and the assembly
differs by several hundred lines--the only change being the order in
which bytes are set. Again this makes no sense. So I have tarballed up
the code I have been working with and posted it here:

http://foobar.caltech.edu/linuxsh/sh-ipl-strange.tar.bz2

The built elf files are in the /debug directory, with the dumped
assembly output and a diff. Right now the only explanation we have come
up with is a byte alignment issue, but the assembly output might suggest
a lot more is wrong.

I would really like to turn optimizations off to debug the assembly
output, but -O2 is apparently needed for I/O.

If any of you with a working stub get a chance, I would enormously
appreciate it if you took a moment to look at my code and see if your
development environment produces similar results. Debugging is
especially difficult for me since it could be anything from the board
(not likely) to the C code (again not likely) to gcc (right now I think
the obvious culprit is the compiler). But since many people are using
kernels built by the exact same compiler, it can't be very buggy and
should be able to build a small 8k stub OK if it can do an 800k kernel.

It really bothers me that I can't explain what is going on here. As I
said above, any and all help would be appreciated. Maybe I am just doing
something really stupid...

Thanks again for your time.

Regards,

Bryan Rittmeyer
mailto:br...@ca...