Re: patch for prologue/epilogue generation

[Bernardo Innocenti <bernie at develer dot com>]

On Friday 22 August 2003 12:00, Gunther Nikl wrote:

> > I've updated the patch. I'm very happy someone is going to test it.
>
>   In the meantime I fixed the old patch because I couldn't wait to test the
>   patch. It differs only in comments from your new version. Attached are
> two modifications.

Thank you very much, I've merged both your changes into my patch. I expecially
liked the optimization of calling m68k_compute_frame_layout() only when
strictly needed.

I'd like to go one step further and just call m68k_compute_frame_layout() once
per function, storing the result somewhere to reuse it later in all of
m68k_initial_elimination_offset() and m68k_output_function_{pro|epi}logue().


> > I can't currently test on a real m68k system, therefore I was quite
> > worried my patch could break something.
>
>   I compiled several testcases with an pre-patch 3.4 and a patched one. I
>   compared the old code with the new code and everything looked fine. The
>   additional +4 are now gone.

Could you please build this test program to check if C++ exceptions are still
working correctly on m68k? (It's attached). It doesn't work on ColdFire.


> > If you can't run the GCC testsuite, please try it on a very large code
> > base, both with and without -fomit-frame-pointer.
>
>   I have no idea how to run the GCC testsuite let alone whether this would
>   work on my non-unix m68k system.

The testsuite is very simple to use if you already have expect and dejagnu
installed. Once you have these in place, you just need to do "make test" to
build and (sometimes) run thousands of small tests covering almost every
feature of GCC.

I've recently been explained how to run it on cross-compiler environments
using the combined source tree. I've seen all of binutils, gcc, gdb and
other stuff build in a single session. dejagnu can use simulators built
into GDB or transfer programs to remote boards using several protocols.

The level of automation is just fascinating...


> > Back when I was debugging this code, I experienced subtle problems
> > sneaking in a Linux kernel that could bootstrap almost perfectly despite
> > the fact that some registers saved on the stack were being overwritten by
> > local vars :-)
>
>   My visual inspection didn't show such a problem.

That's because you're looking at the code _after_ it was debugged ;-)


> > > Then there is another problem (at least for me): the first hunk of the
> > > patch to m68k.c cannot be applied because the diff is missing the ^L
> > > after override_options. This might be caused by the ML (I downloaded
> > > the raw message from the ML)
> >
> > This is a known KMail problem.
>
>   Can't you use a "better" mua?

There are several muas for Linux, but none is 100% perfect. I just wish
KMail had this one thing done right. One day perhaps I'll fix it myself :-)

-- 
  // 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

#include <stdio.h>

void runTest()
{
    printf("Hello world\n");
    throw("Test exception");
}

int main()
{
    try
    {
        runTest();
    }
    
    catch ( const char *msg )
    {
        printf("Caught exception: %s\n", msg);
    }

    printf("Application completed successfully!\n");

    return 0;
}