[PATCH 2.95.3 - WITHDRAWN] Fix powerpc-wrs-vxworks eabi backwards incompatibility.

[David Korn <dkorn at pixelpower dot com>]

   Good morning/afternoon/${TZ} everyone,

              ___
          ___/   \                                 
         /   __  /                                   
         \  (  ) \                                     
         /   --   | <----- This is an egg.                  
         \_/\    /

             \__/                                                  
                                               /###¬             
                      This is my face ------> @ o¬o @    
                                               \ | /       
                             ___                \=/       
                         ___/   \                               
                        /   __   /###¬                                
                        \  (  ) @ o¬o @                 
                        /   --   \ | /                  
                        \_/\    _/\=/                     
                            \__/                  
                                                        
            Egg, meet face. Face, meet egg.
        I just know you two are going to get along great.


  I have been proceeding under a false premise for some time now. When I
first started working on this project I somehow gained the impression that
the size of a ppc va_list had changed between 272 and 2952, which lead me
to the assumption that for backward compatibility I'd have to import the
272 varargs mechanism wholesale. From there, it was just one short but 
deadly leap to the decision to import the entire stack frame layout and
arg placement code. 

  Now I've been back over the whole thing in greater detail, I'm pretty
convinced that that was entirely unneccessary, so I'll rework my patches,
split them up into separate parts, and resubmit them. When I've finished,
there will be an awful lot less changes. Here's my full analysis of
precisely what goes wrong with 2.95.2, varargs, EABI, and VxWorks:


  There are a couple of differences between the 272abi and the 2952abi
in the details of parameter passing and va_arg implementation.

  1) DImode is aligned 32-bit, not 64-bit, when passed on stack. When
   passed in registers it uses the next two GPRs available. Like 2952abi,
   it will not be split between regs and stack, but unlike 2952abi it 
   doesn't care about aligning to use an odd-even register pair. This
   would need to be replicated for compatibility.

  2) DFmode is aligned 32-bit, not 64-bit, when passed on the stack. This
   would need to be replicated for compatibility.

  3) va_arg under 272abi also passes TFmode in FPRs. I do not want to
   replicate *this* bit of behaviour!

  4) va_arg under 272abi won't detect arg type violations. This is another
   bit of backward compatibility we can make do without!

  5) The main reason that 2.95.2 varargs code crashes when working with
   VxWorks is that VxWorks sets up a standard makefile architecture that
   bypasses the header files in $prefix/lib/gcc-lib/$target/$ver/include!
   Instead it provides an auxiliary .h ($includedir/arch/ppc/toolPpc.h)
   that defines va_list and implements the va_ macros based on the 272
   version of va-ppc.h.  This breaks with the 2952 compiler because it
   uses __builtin_args_info(4) to get what used to be varargs_offset,
   but now corresponds to the prototype flag.... you can guess the rest.

  I am now certain that the new constructor-based method for handling PPc
varargs ought to work with VxWorks, which removes my motivation for porting
the entire 272 implementation over in the way I did previously. I won't 
worry about any minor differences in the stack frame layout between 272
and 2952 either; this might break the WRS gdb, in which case I'll just
have to make compatibility patches for the Gnu gdb instead.

  Since VxWorks bypasses the fixinc'ed headers, I can't make use of what
would otherwise be obviously the right way to fix the va_ macros, so that
will have to be handled by providing some installation instructions to
vxworks users. So my plan of action now is :-

  1)  Bin the verbose asm stuff. It may make the source files more
   informative, but it involves the ugliness of exposing toplev.c 
   stuff to the rest of the world.

  2)  Bin the changes that were just meant to keep the stack frame
   layout the same.

  2)  Provide a reworked patch for -mvxcompat272. (I like the name,
   and it does leave our options open if the same situation should
   arise again in the future). This will involve the minimal changes
   needed to implement the EABI differences to DImode and DFmode.
      This patch will also add a new predefine to CPP_SPEC, which I
   will call __VXCOMPAT272__, and which I can then test in a revised
   version of WRS' toolPpc.h to decided whether to #include va-ppc.h
   or to continue to rely on WRS' macros. If I've got to mess with
   the WRS headers, and fixincs can't do it, then at least I want the
   new header to be backwardly compatible with the WRS272 compiler.

 *****Advice needed, please: CPP_SPEC would be the wrong place to
   put -D__VXCOMPAT272__, since it's too global. There's this comment
   in vxppc.h that says

   /* ??? This file redefines CPP_SPEC which is wrong.  It should instead
     define one of the extra specs that gets included in CPP_SPEC.  For
     instance, CPP_OS_DEFAULT_SPEC.  */

   So in order not to make a bad thing worse, I won't add it there. But
  which extra spec should I reuse. Anyone ?*****

  3)  Provide the -mlongcall flag as a separate patch.

  4)  Provide the fix for CALL_V4_[SET/CLEAR]_FP_ARG as another separate
   patch.

 To address Geoff Keating's concerns, I will supply each of these patches
in two versions, one against the gcc-2_95-branch, and one against the
current V3 head-of-tree. Then can they be called backports rather than new
features and go in 2.95.3 ?

  I've also managed to get dejagnu to compile now; the vital clue that I
was missing was "Don't even bother with the tarballs on the Gnu or Cygwin
ftp sites, go and get it out of the CVS", so I can provide test results
too.  I'll try and run them under the simulator and perhaps later get around
to running them under remote control on a real Vx target board.

  Right. That's enough for this mail. Does this sound like an acceptable
plan to everyone ? Does it answer all your concerns ? Have I forgotten
anything ?

     regards,
       DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anythingo
 ffered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to largen
 umbers of others. This is my contribution to the survival of the online
community." 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************