Re: m68k C++ exception handling

[Bernardo Innocenti <bernie at develer dot com>]

On Monday 18 August 2003 11:27, Andreas Schwab wrote:
> Bernardo Innocenti <bernie@develer.com> writes:
> |> C++ exceptions handling appears to be broken on m68k in both GCC 3.3.1
> |> and CVS HEAD (I've tested only on ColdFire targets). This didn't work
> |> also in GCC 2.95.3 with the uClinux patches I've ported forward, so the
> |> cause might be identical.
>
> I tested this on m68k-linux with positive results, but this is already
> quite some time ago.

Could I send you some experimental patches I've applied to my local tree?
If you have time, I'd like you to verify exceptions on m68k-linux with
those patches applied.

So I will be able to guess whether it's something in my patches or a
ColdFire specific problem.


> |> Some random questions:
> |>
> |>  - does the EH handling rely on frame-pointers? Is it supposed to work
> |>    on all platforms even with -fomit-frame-pointers?
>
> This was also tested on m68k-linux, and seems to work fine.  The DWARF2
> unwind information is supposed to describe exactly where all the registers
> are saved, independent of the frame pointer.

Where is this information emitted exactly? If it's that dwarf stuff in
m68k_output_function_prologue(), it's way possible that I didn't get it
right in the first place.

One odd thing I'm seeing with gdb is that the topmost frame in backtraces
almost always comes out wrong (i.e.: "????"), while previous frames look
right but I never get more than 2-3...


> |>  - How are __builtin_extract_return_addr() and
> |> __builtin_return_address() supposed to work? Do they need some special
> |> support in back-ends?
>
> Only __builtin_return_address with an argument > 0 requires a frame
> pointer, otherwise the place of the return address is known by the frame
> size, and the generic code works fine on m68k.

The stack unwinding code always calls __builtin_return_address(0), so it's
not that either.


> |>  - It's way possible that the EH stuff works fine on all m68k platforms
> |>    except ColdFire, perhaps because of the different frame layout.
> |>    I'd really much like to know if the test program works on other
> |>    m68k targets and on embedded boards (no uClinux).
>
> The testsuite runs successfully on m68k-linux, at least it did the last
> time I checked.  In which way does the frame layout differ on ColdFire?

ColdFire cores don't have the (An)+ and -(An) addressing modes for
destination operand of the movem instruction. The '(An)' addressing mode
still increments the pointer after moving each source register, but the
final value is never written back to the address register.

This is what a notmal m68k prologue/epilogue would do:

	link	#-frame_size,a6
	movm	regs_to_save,-(sp)

	[...]

	movm	(sp)+,regs_to_save
	unlk	a6
	rts

And this is how you would it do on a ColdFire:

	link	#-frame_size_with_regs,a6
	movm	regs_to_save,(fp)

	[...]

	movm	(fp),regs_to_save
	unlk	a6
	rts

Seems simple, but it takes quite a lot of intrusive changes in
m68k_output_function_(prologue|epilogue) to get it right in all
cases, with and without the frame pointer.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html