Re: bootstrap/3589: GCC 3.0-CVS illegal instruction on hppa1.1-proelf

[Vladimir Makarov <vmakarov@redhat.com>]

The following reply was made to PR bootstrap/3589; it has been noted by GNATS.

From: Vladimir Makarov <vmakarov@redhat.com>
To: Joel Sherrill <joel.sherrill@OARcorp.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org, vmakarov@gcc.gnu.org,
        joel@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: bootstrap/3589: GCC 3.0-CVS illegal instruction on hppa1.1-proelf
Date: Wed, 27 Mar 2002 13:52:05 -0500

 Joel Sherrill wrote:
 > 
 > Vladimir Makarov wrote:
 > >
 > > Joel Sherrill wrote:
 > > >
 > > > Vladimir Makarov wrote:
 > > > >
 > > > > Joel Sherrill wrote:
 > > > > >
 > > > > > Vladimir Makarov wrote:
 > > > > > >
 > > > > > > Joel Sherrill wrote:
 > > > > > > >
 > > > > > > > Vladimir Makarov wrote:
 > > > > > > > >
 > > > > > > > > Joel Sherrill wrote:
 > > > > > > > > >
 > > > > > > > > > Vladimir Makarov wrote:
 > > > > > > > > > >
 > > > > > > > > > > Joel Sherrill wrote:
 > > > > > > > > > >
 > > > > > > > > > > >Is there any ifdef to check and decide which directives to use?
 > > > > > > > > > > >
 > > > > > > > > > > > And if there is any reference mapping between them, I would appreciate
 > > > > > > > > > > > knowing about it.
 > > > > > > > > > >
 > > > > > > > > > > Here is the path solving the problem.
 > > > > > > > > > >
 > > > > > > > > > > You could find a description of the pseudoops and mapping them into elf
 > > > > > > > > > > sections in
 > > > > > > > > > >
 > > > > > > > > > > http://segfault.net/~scut/cpu/hppa/HP_Assembler_Reference_Manual_HP9000_9th_Ed.pdf
 > > > > > > > > >
 > > > > > > > > > Thanks.
 > > > > > > > > >
 > > > > > > > > > Could the __PRO__ (or something similar) be part of the cpp predefines
 > > > > > > > > > for this
 > > > > > > > > > configuration so non-gcc assembly can do the right thing?  I know that
 > > > > > > > > > at least
 > > > > > > > > > libgloss and RTEMS have hppa assembly.
 > > > > > > > > >
 > > > > > > > >
 > > > > > > > > Yes, we could do it.  But it is not urgent now.  Libgloss has no
 > > > > > > > > .subspace directive so it should be compiled without problems.
 > > > > > > >
 > > > > > > > OK.  There are some in RTEMS but I am happy to disable them.  The hppa
 > > > > > > > port (when really active) was maintained on on an hpux box using gcc
 > > > > > > > and native as/ld.  So getting to the point where it is built using
 > > > > > >
 > > > > > >   Here the rewritten patch is.  __PRO__ is now always defined for
 > > > > > > hppa1.1-*-pro* and hppa1.1-*-rtems*.  Please ignore the previous patch
 > > > > > > (__PRO__ was used only for libgcc compilation in it).
 > > > > >
 > > > > > I hate to say this but hppa1.1-*-rtems* includes config/pa/rtems.h after
 > > > > > config/pa/pa-pro-end.h so ends up overriding the CPP_PREDEFINES
 > > > > > settings.
 > > > > > So -D__PRO__ has to be added to config/pa/rtems.h as well.
 > > > > >
 > > > > > It isn't obvious because the include order is from config.gcc but this
 > > > > > is basically how all of the *-rtems* targets are constructed.  We
 > > > > > baseline
 > > > > > another similar target and slightly modify it for RTEMS. :)
 > > > > >
 > > > >   Sorry, I've missed this.  rtems.h is really after pa-pro-end.h in
 > > > > config.gcc for rtems.
 > > > > I think it is even better because __PRO__ will be defined only for
 > > > > hppa1.1-*pro*.
 > > > > hppa1.1-*-rtems* will have __rtems__ (which is already defined in
 > > > > CPP_PREDEFINES in pa/rtmems.h).
 > > >
 > > > > So I'd add only proccessing __rtems__ into lib2funcs.asm to this patch.
 > > > > Is it ok for you?
 > > > >
 > > > > I'd also use __pro__ instead __PRO__ (because __rtems__ use lower
 > > > > letters).  What do you think, Joel.
 > > >
 > > > Given the target, I don't really care :) but in general I would prefer
 > > > that the conditional indicate the assembler to be used independent of
 > > > the OS or lack thereof.
 > > >
 > >
 > > It is hard to achieve.  Of course the used object file format is major.
 > > So we could define __elfobj__ in pro-end.h and rtems.h.  But they are
 > > connected with elf only config.gcc.  Somebody could create
 > > hppa1.1-*-prosom using pro-end.h.  Of course it is stupid because there
 > > is only proelf.
 > >
 > > So I think the following patch is still reasonable.
 > 
 > OK -- fine with me.  I feel like I am flogging a dead horse since all
 > we are doing is mitigating bit rot. :)
 > 
 > Does the target build for you now with c/c++ enabled?
 > 
 > > 2002-03-26  Vladimir Makarov  <vmakarov@redhat.com>
 > >
 > >         * pa/pa-pro-end.h (CPP_PREDEFINES): Add -D__pro__.
 > >
 > >         * pa/lib2funcs.asm: Don't use .SPACE and .SUBSPACE if __pro__
 > >         or __rtems_ is defined.
 > >
 > > Index: pa/lib2funcs.asm
 > > ===================================================================
 > > RCS file: /cvs/gcc/gcc/gcc/config/pa/lib2funcs.asm,v
 > > retrieving revision 1.6
 > > diff -u -p -r1.6 lib2funcs.asm
 > > --- lib2funcs.asm       2001/04/16 18:30:45     1.6
 > > +++ lib2funcs.asm       2002/03/26 22:13:04
 > > @@ -28,6 +28,7 @@
 > >  ;  the Free Software Foundation, 59 Temple Place - Suite 330,
 > >  ;  Boston, MA 02111-1307, USA.
 > >
 > > +#if !defined(__pro__) && !defined(__rtems__)
 > >         .SPACE $PRIVATE$
 > >         .SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31
 > >         .SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
 > > @@ -35,11 +36,14 @@
 > >         .SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44
 > >         .SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
 > >         .SUBSPA $MILLICODE$,QUAD=0,ALIGN=8,ACCESS=44,SORT=8
 > > -
 > > +#endif
 > >         .IMPORT $$dyncall,MILLICODE
 > > +#if !defined(__pro__) && !defined(__rtems__)
 > >         .SPACE $TEXT$
 > >         .SUBSPA $CODE$
 > > -
 > > +#else
 > > +       .text
 > > +#endif
 > >  ; Simply call with the address of the desired import stub in %r22 and
 > >  ; arguments in the normal place (%r26-%r23 and stack slots).
 > >  ;
 > > Index: pa/pa-pro-end.h
 > > ===================================================================
 > > RCS file: /cvs/gcc/gcc/gcc/config/pa/pa-pro-end.h,v
 > > retrieving revision 1.5
 > > diff -u -p -r1.5 pa-pro-end.h
 > > --- pa-pro-end.h        2000/11/02 23:29:12     1.5
 > > +++ pa-pro-end.h        2002/03/26 22:13:04
 > > @@ -30,7 +30,7 @@ Boston, MA 02111-1307, USA.  */
 > >  #define LIB_SPEC "%{!p:%{!pg:-lc}}%{p: -L/lib/libp/ -lc}%{pg:
 > > -L/lib/libp/ -lc}"
 > >
 > >  #undef CPP_PREDEFINES
 > > -#define CPP_PREDEFINES "-Dhppa -DPWB -Acpu=hppa -Amachine=hppa"
 > > +#define CPP_PREDEFINES "-Dhppa -DPWB -D__pro__ -Acpu=hppa
 > > -Amachine=hppa"
 > >
 
 
   There is another problem of building toolchains hppa1.1-*-pro* and
 hppa1.1-*-rtems*.  The reason of problem is in that .comm has syntax
 different from standard elf one and has no field defining alignment.
 
   The following patch solves the problem.
 
   I close the PR.
 
 Vlad
 
 
 2002-03-27  Vladimir Makarov  <vmakarov@redhat.com>
 
         * config/pa/elf.h (ASM_OUTPUT_ALIGNED_LOCAL): Redefine it.
 
 Index: gcc/config/pa/elf.h
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/config/pa/elf.h,v
 retrieving revision 1.12
 diff -c -p -r1.12 elf.h
 *** elf.h       2002/01/04 15:43:30     1.12
 --- elf.h       2002/03/27 18:50:09
 *************** do {  \
 *** 98,103 ****
 --- 98,112 ----
          fputs (",ENTRY\n", FILE);                                     
 \
        } while (0)
   
 + #undef ASM_OUTPUT_ALIGNED_LOCAL
 + #define ASM_OUTPUT_ALIGNED_LOCAL(FILE, NAME, SIZE, ALIGNED)          
 \
 + {                                                                    
 \
 +   bss_section ();                                                    
 \
 +   fprintf ((FILE), "\t.align %d\n", ((ALIGNED) / BITS_PER_UNIT));    
 \
 +   assemble_name ((FILE), (NAME));                                    
 \
 +   fprintf ((FILE), "\n\t.block %d\n",
 (SIZE));                                \
 + }
 +   
   /* Biggest alignment supported by the object file format of this
      machine.  Use this macro to limit the alignment which can be
      specified using the `__attribute__ ((aligned (N)))' construct.  If