[openrisc] Urgent: bug in newest gcc...

[Chris Ziomkowski<chris@asics.ws>]

gdb is failing with the version of gcc I checked out from
cvs on Monday. I have tracked this down to the following
problem. The code below is generated by running this version
of gcc on the file dhry.c in or1ksim/testbench/dhrystone with
the options:

or32-rtems-gcc -mhard-div -S -DOR1K dhry.c

I have left out the unimportant sections. The issue is with the
frame register, r2, and it can be found immediately. The program
starts up by calling main:
-------------------------------------
proc _main
	.global _main
_main:

	# 00111110011100000000000000000000
	# gpr_save_area 4 vars 192 current_function_outgoing_args_size 0
	l.addi   	r1,r1,-204
	l.addi   	r2,r1,204
	l.sw     	4(r1),r2
	l.sw     	0(r1),r9
	l.sw    	8(r1),r10
	l.jal   	___main
	l.nop			# nop delay slot
	l.movhi 	r3,hi(_Next_Ptr_Glob)	 # move immediate (high)
	l.ori  	r3,r3,lo(_Next_Ptr_Glob)	 # move immediate (low)

Space is allocated on the stack for 204 bytes, the stack
pointer r1 is moved down, and the frame pointer r2 is set to
the original stack position. The current frame, the current
link register, and r10 are saved.

1) Question: What is r10? Why is it being saved? It has yet
to be used by anything. The documentation doesn't list it as
anything special, and the ___main function doesn't use it...
This is secondary to my immediate concern, however.

We now jump to ___main which is defined as follows:
--------------------------------------
proc ___main
	.global ___main
___main:

	# 00100000000000000000000000000000
	# gpr_save_area 0 vars 0 current_function_outgoing_args_size 0
	l.addi   	r1,r1,-4
	l.addi   	r2,r1,4
	l.sw     	0(r1),r2
L8:
	l.lwz    	r2,0(r1)
	l.jalr  	r9
	l.addi   	r1,r1,4
endproc ___main


The prologue code for this function does the same thing. It adds
space for 4 bytes (to store the previous frame), and then resets
the frame register to the current stack location.

Since this function does nothing, it immediately exits. But the
frame register (r1) is not reset to the original value! Instead,
it is reset to the current value which was stored!

My guess is that the two instructions:

	l.addi   	FRAME,STACK,#Bytes
	l.sw     	0(STACK),FRAME

in the prologue have been misordered, and what was meant was:

	l.sw		0(STACK),FRAME
	l.addi		FRAME,STACK,#Bytes


However, I can not find the location in the gcc source
code where this occurs. 

2) Can someone point me to the location in gcc where this
is being done so that I can fix the problem?

gdb is ignoring breakpoints because the frame register
doesn't match after a function call. This used to work
on the gcc version a few weeks ago, and I can't do anything
until this is fixed.

Thanks,

Chris
chris@asics.ws




_______________________________________________________
www.asics.ws - Solutions for your ASIC needs
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml