News MIPS option -mno-shared

News MIPS option -mno-shared

[Ian Lance Taylor]

I'd like to see whether anybody has an opinion about this patch before
I check it in.

This patch adds a new option to the MIPS assembler: -mno-shared.
Normally the .cpload pseudo-op generates code which looks like this:

	lui	$gp,%hi(_gp_disp)
	addiu	$gp,$gp,%lo(_gp_disp)
	addu	$gp,$gp,.cpload argument

With -mno-shared, the .cpload pseudo-op will generate code that looks
like this:

	lui	$gp,%hi(_gp)
	addiu	$gp,$gp,%lo(_gp)

The idea is that you can use -KPIC -mno-shared and get code which
still uses the usual Unix calling convention, but is slightly more
efficient at each function entry.  Of course, the resulting code is
not position independent and can not be put into a shared library.
Hence the name -mno-shared.  (Note that nothing will prevent you from
trying to put -mno-shared code into a shared library, but the
resulting shared library will not work correctly.)

Of course the new MIPS ABI does not use .cpload.  I have a different
patch adding -mno-shared to gcc, but since gcc is currently in stage 3
I'll wait on submitting that.

This patch relies on the fact that the GNU linker always defines the
symbol _gp to be the value that should go into the $gp register.

Does anybody want to comment on this patch before I check it in?

Ian

Index: config/tc-mips.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-mips.c,v
retrieving revision 1.275
diff -p -u -r1.275 tc-mips.c
--- config/tc-mips.c	9 Dec 2004 06:17:14 -0000	1.275
+++ config/tc-mips.c	9 Dec 2004 15:03:26 -0000
@@ -136,6 +136,10 @@ static enum mips_abi_level mips_abi = NO
 /* Whether or not we have code that can call pic code.  */
 int mips_abicalls = FALSE;
 
+/* Whether or not we have code which can be put into a shared
+   library.  */
+static bfd_boolean mips_in_shared = TRUE;
+
 /* This is the set of options which may be modified by the .set
    pseudo-op.  We use a struct so that .set push and .set pop are more
    reliable.  */
@@ -3386,10 +3390,12 @@ macro_build_lui (expressionS *ep, int re
   else
     {
       assert (ep->X_op == O_symbol);
-      /* _gp_disp is a special case, used from s_cpload.  */
+      /* _gp_disp is a special case, used from s_cpload.  _gp is used
+	 if mips_no_shared.  */
       assert (mips_pic == NO_PIC
 	      || (! HAVE_NEWABI
-		  && strcmp (S_GET_NAME (ep->X_add_symbol), "_gp_disp") == 0));
+		  && (strcmp (S_GET_NAME (ep->X_add_symbol), "_gp_disp") == 0
+		      || strcmp (S_GET_NAME (ep->X_add_symbol), "_gp") == 0)));
       *r = BFD_RELOC_HI16_S;
     }
 
@@ -10118,10 +10124,14 @@ struct option md_longopts[] =
 #define OPTION_NO_RELAX_BRANCH (OPTION_MISC_BASE + 11)
   {"relax-branch", no_argument, NULL, OPTION_RELAX_BRANCH},
   {"no-relax-branch", no_argument, NULL, OPTION_NO_RELAX_BRANCH},
+#define OPTION_MSHARED (OPTION_MISC_BASE + 12)
+#define OPTION_MNO_SHARED (OPTION_MISC_BASE + 13)
+  {"mshared", no_argument, NULL, OPTION_MSHARED},
+  {"mno-shared", no_argument, NULL, OPTION_MNO_SHARED},
 
   /* ELF-specific options.  */
 #ifdef OBJ_ELF
-#define OPTION_ELF_BASE    (OPTION_MISC_BASE + 12)
+#define OPTION_ELF_BASE    (OPTION_MISC_BASE + 14)
 #define OPTION_CALL_SHARED (OPTION_ELF_BASE + 0)
   {"KPIC",        no_argument, NULL, OPTION_CALL_SHARED},
   {"call_shared", no_argument, NULL, OPTION_CALL_SHARED},
@@ -10334,6 +10344,14 @@ md_parse_option (int c, char *arg)
       mips_relax_branch = 0;
       break;
 
+    case OPTION_MSHARED:
+      mips_in_shared = TRUE;
+      break;
+
+    case OPTION_MNO_SHARED:
+      mips_in_shared = FALSE;
+      break;
+
 #ifdef OBJ_ELF
       /* When generating ELF code, we permit -KPIC and -call_shared to
 	 select SVR4_PIC, and -non_shared to select no PIC.  This is
@@ -11792,12 +11810,21 @@ s_abicalls (int ignore ATTRIBUTE_UNUSED)
 	lui	$gp,%hi(_gp_disp)
 	addiu	$gp,$gp,%lo(_gp_disp)
 	addu	$gp,$gp,.cpload argument
-   The .cpload argument is normally $25 == $t9.  */
+   The .cpload argument is normally $25 == $t9.
+
+   The -mno-shared option changes this to:
+	lui	$gp,%hi(_gp)
+	addiu	$gp,$gp,%lo(_gp)
+   and the argument is ignored.  This saves an instruction, but the
+   resulting code is not position independent; it uses an absolute
+   address for _gp.  Thus code assembled with -mno-shared can go into
+   an ordinary executable, but not into a shared library.  */
 
 static void
 s_cpload (int ignore ATTRIBUTE_UNUSED)
 {
   expressionS ex;
+  int reg;
 
   /* If we are not generating SVR4 PIC code, or if this is NewABI code,
      .cpload is ignored.  */
@@ -11811,8 +11838,10 @@ s_cpload (int ignore ATTRIBUTE_UNUSED)
   if (mips_opts.noreorder == 0)
     as_warn (_(".cpload not in noreorder section"));
 
+  reg = tc_get_register (0);
+
   ex.X_op = O_symbol;
-  ex.X_add_symbol = symbol_find_or_make ("_gp_disp");
+  ex.X_add_symbol = symbol_find_or_make (mips_in_shared ? "_gp_disp" : "_gp");
   ex.X_op_symbol = NULL;
   ex.X_add_number = 0;
 
@@ -11823,8 +11852,9 @@ s_cpload (int ignore ATTRIBUTE_UNUSED)
   macro_build_lui (&ex, mips_gp_register);
   macro_build (&ex, "addiu", "t,r,j", mips_gp_register,
 	       mips_gp_register, BFD_RELOC_LO16);
-  macro_build (NULL, "addu", "d,v,t", mips_gp_register,
-	       mips_gp_register, tc_get_register (0));
+  if (mips_in_shared)
+    macro_build (NULL, "addu", "d,v,t", mips_gp_register,
+		 mips_gp_register, reg);
   macro_end ();
 
   demand_empty_rest_of_line ();
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gas/NEWS,v
retrieving revision 1.66
diff -p -u -r1.66 NEWS
--- NEWS	8 Nov 2004 13:17:12 -0000	1.66
+++ NEWS	9 Dec 2004 15:03:26 -0000
@@ -19,6 +19,8 @@
 * Support for ColdFire EMAC instructions added and Motorola syntax for MAC/EMAC
   instrucitons.
 
+* New command line option -mno-shared for MIPS ELF targets.
+
 * New command line option --alternate and pseudo-ops .altmacro and .noaltmacro
   added to enter (and leave) alternate macro syntax mode.
 
Index: doc/c-mips.texi
===================================================================
RCS file: /cvs/src/src/gas/doc/c-mips.texi,v
retrieving revision 1.31
diff -p -u -r1.31 c-mips.texi
--- doc/c-mips.texi	14 Apr 2004 07:48:48 -0000	1.31
+++ doc/c-mips.texi	9 Dec 2004 15:03:26 -0000
@@ -238,6 +238,16 @@ error is detected.  This is the default.
 @itemx -mno-pdr
 Control generation of @code{.pdr} sections.  Off by default on IRIX, on
 elsewhere.
+
+@item -mshared
+@itemx -mno-shared
+When generating code using the Unix calling conventions (selected by
+@samp{-KPIC} or @samp{-mcall_shared}), gas will normally generate code
+which can go into a shared library.  The @samp{-mno-shared} option
+tells gas to generate code which uses the calling convention, but can
+not go into a shared library.  The resulting code is slightly more
+efficient.  This option only affects the handling of the
+@samp{.cpload} pseudo-op.
 @end table
 
 @node MIPS Object

Re: News MIPS option -mno-shared

[Richard Sandiford]

Ian Lance Taylor <ian@wasabisystems.com> writes:
> This patch adds a new option to the MIPS assembler: -mno-shared.
> Normally the .cpload pseudo-op generates code which looks like this:
>
> 	lui	$gp,%hi(_gp_disp)
> 	addiu	$gp,$gp,%lo(_gp_disp)
> 	addu	$gp,$gp,.cpload argument
>
> With -mno-shared, the .cpload pseudo-op will generate code that looks
> like this:
>
> 	lui	$gp,%hi(_gp)
> 	addiu	$gp,$gp,%lo(_gp)
>
> The idea is that you can use -KPIC -mno-shared and get code which
> still uses the usual Unix calling convention, but is slightly more
> efficient at each function entry.

Yeah, this has been on my to-do list for a while ;)  Are you going to
do the same thing for n32 or are you only interested in o32?

FWIW, the patch looks good to me if it's o32 only.

Richard

Re: News MIPS option -mno-shared

[Ian Lance Taylor]

Richard Sandiford <rsandifo@redhat.com> writes:

> Ian Lance Taylor <ian@wasabisystems.com> writes:
> > This patch adds a new option to the MIPS assembler: -mno-shared.
> > Normally the .cpload pseudo-op generates code which looks like this:
> >
> > 	lui	$gp,%hi(_gp_disp)
> > 	addiu	$gp,$gp,%lo(_gp_disp)
> > 	addu	$gp,$gp,.cpload argument
> >
> > With -mno-shared, the .cpload pseudo-op will generate code that looks
> > like this:
> >
> > 	lui	$gp,%hi(_gp)
> > 	addiu	$gp,$gp,%lo(_gp)
> >
> > The idea is that you can use -KPIC -mno-shared and get code which
> > still uses the usual Unix calling convention, but is slightly more
> > efficient at each function entry.
> 
> Yeah, this has been on my to-do list for a while ;)  Are you going to
> do the same thing for n32 or are you only interested in o32?

For n32 the patch is to gcc, not the binutils.  I have that patch, but
it's a new feature and as such is not going to be acceptable in stage
3.  I'll submit it when gcc goes back to stage 1.

The gcc patch looks more or like the following, plus some obvious
mips.h and doc stuff.

Ian

Index: mips.c
===================================================================
RCS file: /cvsroot/gnu/gcc/config/mips/mips.c,v
retrieving revision 1.3.4.2
retrieving revision 1.3.4.6
diff -u -r1.3.4.2 -r1.3.4.6
--- mips.c	21 Sep 2004 05:10:50 -0000	1.3.4.2
+++ mips.c	11 Nov 2004 23:44:38 -0000	1.3.4.6
@@ -145,7 +145,11 @@
 
    SYMBOL_GOTOFF_LOADGP
        An UNSPEC wrapper around a function's address.  It represents the
-       offset of _gp from the start of the function.  */
+       offset of _gp from the start of the function.
+
+   SYMBOL_GP
+       An UNSPEC wrapper around the _gp symbol.  This is the absolute
+       value of _gp.  */
 enum mips_symbol_type {
   SYMBOL_GENERAL,
   SYMBOL_SMALL_DATA,
@@ -155,9 +159,10 @@
   SYMBOL_GOTOFF_PAGE,
   SYMBOL_GOTOFF_GLOBAL,
   SYMBOL_GOTOFF_CALL,
-  SYMBOL_GOTOFF_LOADGP
+  SYMBOL_GOTOFF_LOADGP,
+  SYMBOL_GP
 };
-#define NUM_SYMBOL_TYPES (SYMBOL_GOTOFF_LOADGP + 1)
+#define NUM_SYMBOL_TYPES (SYMBOL_GP + 1)
 
 
 /* Classifies an address.
@@ -970,6 +975,7 @@
     case SYMBOL_GOTOFF_GLOBAL:
     case SYMBOL_GOTOFF_CALL:
     case SYMBOL_GOTOFF_LOADGP:
+    case SYMBOL_GP:
       return false;
     }
   abort ();
@@ -1060,6 +1066,7 @@
     case SYMBOL_GOTOFF_GLOBAL:
     case SYMBOL_GOTOFF_CALL:
     case SYMBOL_GOTOFF_LOADGP:
+    case SYMBOL_GP:
       return true;
     }
   abort ();
@@ -1185,6 +1192,11 @@
     case SYMBOL_GOTOFF_LOADGP:
       /* Check whether the offset is a 16- or 32-bit value.  */
       return mips_split_p[type] ? 2 : 1;
+
+    case SYMBOL_GP:
+      if (ABI_HAS_64BIT_SYMBOLS)
+	abort ();
+      return 2;
     }
   abort ();
 }
@@ -5145,6 +5163,13 @@
       mips_split_p[SYMBOL_GOTOFF_LOADGP] = true;
       mips_hi_relocs[SYMBOL_GOTOFF_LOADGP] = "%hi(%neg(%gp_rel(";
       mips_lo_relocs[SYMBOL_GOTOFF_LOADGP] = "%lo(%neg(%gp_rel(";
+
+      if (! ABI_HAS_64BIT_SYMBOLS)
+	{
+	  mips_split_p[SYMBOL_GP] = true;
+	  mips_hi_relocs[SYMBOL_GP] = "%hi(";
+	  mips_lo_relocs[SYMBOL_GP] = "%lo(";
+	}
     }
 }
 
@@ -6643,12 +6686,24 @@
 {
   if (TARGET_ABICALLS && TARGET_NEWABI && cfun->machine->global_pointer > 0)
     {
-      rtx addr, offset, incoming_address;
+      if (TARGET_SHARED || ABI_HAS_64BIT_SYMBOLS || TARGET_MIPS16)
+	{
+	  rtx addr, offset, incoming_address;
 
-      addr = XEXP (DECL_RTL (current_function_decl), 0);
-      offset = mips_unspec_address (addr, SYMBOL_GOTOFF_LOADGP);
-      incoming_address = gen_rtx_REG (Pmode, PIC_FUNCTION_ADDR_REGNUM);
-      emit_insn (gen_loadgp (offset, incoming_address));
+	  addr = XEXP (DECL_RTL (current_function_decl), 0);
+	  offset = mips_unspec_address (addr, SYMBOL_GOTOFF_LOADGP);
+	  incoming_address = gen_rtx_REG (Pmode, PIC_FUNCTION_ADDR_REGNUM);
+	  emit_insn (gen_loadgp (offset, incoming_address));
+	}
+      else
+	{
+	  rtx addr;
+
+	  addr = mips_unspec_address (gen_rtx_SYMBOL_REF (Pmode, "_gp"),
+				      SYMBOL_GP);
+	  emit_move_insn (pic_offset_table_rtx,
+			  mips_split_symbol (pic_offset_table_rtx, addr));
+	}
       if (!TARGET_EXPLICIT_RELOCS)
 	emit_insn (gen_loadgp_blockage ());
     }

Re: News MIPS option -mno-shared

[Thiemo Seufer]

Ian Lance Taylor wrote:
> I'd like to see whether anybody has an opinion about this patch before
> I check it in.
> 
> This patch adds a new option to the MIPS assembler: -mno-shared.
> Normally the .cpload pseudo-op generates code which looks like this:
> 
> 	lui	$gp,%hi(_gp_disp)
> 	addiu	$gp,$gp,%lo(_gp_disp)
> 	addu	$gp,$gp,.cpload argument
> 
> With -mno-shared, the .cpload pseudo-op will generate code that looks
> like this:
> 
> 	lui	$gp,%hi(_gp)
> 	addiu	$gp,$gp,%lo(_gp)
> 
> The idea is that you can use -KPIC -mno-shared and get code which
> still uses the usual Unix calling convention, but is slightly more
> efficient at each function entry.  Of course, the resulting code is
> not position independent and can not be put into a shared library.
> Hence the name -mno-shared.

It will also break 64bit addressing. IMHO it should check for that,
and either fail or fall back to the old code sequence.


Thiemo

Re: News MIPS option -mno-shared

[David Daney]

Ian Lance Taylor wrote:
> I'd like to see whether anybody has an opinion about this patch before
> I check it in.
> 
> This patch adds a new option to the MIPS assembler: -mno-shared.
> Normally the .cpload pseudo-op generates code which looks like this:
> 
> 	lui	$gp,%hi(_gp_disp)
> 	addiu	$gp,$gp,%lo(_gp_disp)
> 	addu	$gp,$gp,.cpload argument
> 
> With -mno-shared, the .cpload pseudo-op will generate code that looks
> like this:
> 
> 	lui	$gp,%hi(_gp)
> 	addiu	$gp,$gp,%lo(_gp)
> 

I have code that generates stack traces that relies on the structure of the
function prolog to work.  It looks for this:

        /*
         * Find function prolog.  It will have the form:
         *
         *	3c1c???? 	lui	gp,????
         *	279c???? 	addiu	gp,gp,????
         *	0399e021 	addu	gp,gp,t9
         *	27bd#### 	addiu	sp,sp,####
         *
         * Where ???? are the offset of the GOT from the function
         * entrypoint, and #### is the amount added to the stack poiner.
         */

Your change will break it.

Being the moderately astute person that I am, I will be able to fix my code
to work with the optimized prolog.

I wonder if others will be effected as well.

David Daney.

Re: News MIPS option -mno-shared

[Maciej W. Rozycki]

On Thu, 9 Dec 2004, Ian Lance Taylor wrote:

> The idea is that you can use -KPIC -mno-shared and get code which
> still uses the usual Unix calling convention, but is slightly more
> efficient at each function entry.  Of course, the resulting code is
> not position independent and can not be put into a shared library.

 The resulting naming of options is a bit unfortunate -- -KPIC suggests 
the result is PIC regardless of other options.

> Hence the name -mno-shared.  (Note that nothing will prevent you from
> trying to put -mno-shared code into a shared library, but the
> resulting shared library will not work correctly.)

 Shouldn't the relocations be forwarded to the .rel.dyn section upon
static linking for resolution (or complaint) by ld.so?  Like it happens
for other platforms where you can build PDC shared libraries that still
work.  Not that such libraries are optimal, but still better than ones
that silently break.

  Maciej

Re: News MIPS option -mno-shared

[David Daney]

Ian Lance Taylor wrote:
> I'd like to see whether anybody has an opinion about this patch before
> I check it in.
> 
> This patch adds a new option to the MIPS assembler: -mno-shared.
> Normally the .cpload pseudo-op generates code which looks like this:
> 
> 	lui	$gp,%hi(_gp_disp)
> 	addiu	$gp,$gp,%lo(_gp_disp)
> 	addu	$gp,$gp,.cpload argument
> 
> With -mno-shared, the .cpload pseudo-op will generate code that looks
> like this:
> 
> 	lui	$gp,%hi(_gp)
> 	addiu	$gp,$gp,%lo(_gp)
> 

Will this work when ld generates multiple GOTs?

David Daney.

Re: News MIPS option -mno-shared

[Ian Lance Taylor]

David Daney <ddaney@avtrex.com> writes:

> I have code that generates stack traces that relies on the structure of the
> function prolog to work.  It looks for this:
> 
>         /*
>          * Find function prolog.  It will have the form:
>          *
>          *	3c1c???? 	lui	gp,????
>          *	279c???? 	addiu	gp,gp,????
>          *	0399e021 	addu	gp,gp,t9
>          *	27bd#### 	addiu	sp,sp,####
>          *
>          * Where ???? are the offset of the GOT from the function
>          * entrypoint, and #### is the amount added to the stack poiner.
>          */
> 
> Your change will break it.

True, but only if you choose to use -mno-shared when you compile.  I'm
not proposing that it be the default, only that it be an option.

Ian

Re: News MIPS option -mno-shared

[Ian Lance Taylor]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:

> On Thu, 9 Dec 2004, Ian Lance Taylor wrote:
> 
> > The idea is that you can use -KPIC -mno-shared and get code which
> > still uses the usual Unix calling convention, but is slightly more
> > efficient at each function entry.  Of course, the resulting code is
> > not position independent and can not be put into a shared library.
> 
>  The resulting naming of options is a bit unfortunate -- -KPIC suggests 
> the result is PIC regardless of other options.

The option naming in general is somewhat confusing.  -KPIC doesn't
really mean PIC in the sense that -fpic does to gcc.  It means to use
the Unix calling conventions, which are designed to be PIC.  -KPIC
affects how some pseudo-ops and instructions like jal are interpreted.
You can easily write non-PIC code while using -KPIC.  A synonym for
-KPIC is -mcall_shared, which is perhaps a better name.

> > Hence the name -mno-shared.  (Note that nothing will prevent you from
> > trying to put -mno-shared code into a shared library, but the
> > resulting shared library will not work correctly.)
> 
>  Shouldn't the relocations be forwarded to the .rel.dyn section upon
> static linking for resolution (or complaint) by ld.so?  Like it happens
> for other platforms where you can build PDC shared libraries that still
> work.  Not that such libraries are optimal, but still better than ones
> that silently break.

I don't think it will work, because the resulting relocation will be
against the _gp symbol, which is specific to the executable, not to
the shared link of the executable and the shared library.  The dynamic
linker will probably use the wrong value of _gp when resolving this
relocation.  I suppose it would be possible to make it work through
some further hackery, but I doubt anybody would really want to use it.

Ian

Re: News MIPS option -mno-shared

[Ian Lance Taylor]

David Daney <ddaney@avtrex.com> writes:

> Ian Lance Taylor wrote:
> > I'd like to see whether anybody has an opinion about this patch before
> > I check it in.
> > 
> > This patch adds a new option to the MIPS assembler: -mno-shared.
> > Normally the .cpload pseudo-op generates code which looks like this:
> > 
> > 	lui	$gp,%hi(_gp_disp)
> > 	addiu	$gp,$gp,%lo(_gp_disp)
> > 	addu	$gp,$gp,.cpload argument
> > 
> > With -mno-shared, the .cpload pseudo-op will generate code that looks
> > like this:
> > 
> > 	lui	$gp,%hi(_gp)
> > 	addiu	$gp,$gp,%lo(_gp)
> > 
> 
> Will this work when ld generates multiple GOTs?

Hmmm, I don't know enough about how the MIPS linker handles multiple
GOTs to know for sure.  My reading of the code indicates to me that it
will.  It seems that relocations against _gp_disp always use a single
value for the output BFD, in which case the above code sequence will
work too.  Can somebody tell me whether this is not the case, and, if
so, how to determine the correct GP value to use when calculating
_gp_disp?

Ian

Re: News MIPS option -mno-shared

[Richard Sandiford]

Ian Lance Taylor <ian@wasabisystems.com> writes:
>> Yeah, this has been on my to-do list for a while ;)  Are you going to
>> do the same thing for n32 or are you only interested in o32?
>
> For n32 the patch is to gcc, not the binutils.  I have that patch, but
> it's a new feature and as such is not going to be acceptable in stage
> 3.  I'll submit it when gcc goes back to stage 1.

OK.  I was just wondering if there was a specific reason for making
.cpload (the o32 pseudo-op) use _gp but not .cpsetup (the n32 pseudo-op).
I realise that most n32 code uses %hi/lo(%neg(%gp_rel(...))) directly,
but some hand-written asm does use .cpsetup.

> The gcc patch looks more or like the following, plus some obvious
> mips.h and doc stuff.

Looks good, but would it be possible to use SYMBOL_GENERAL instead of
adding a new symbol type like SYMBOL_GP?  In hindsight, "SYMBOL_ABSOLUTE"
would probably have been a better name than SYMBOL_GENERAL.

Richard

RE: News MIPS option -mno-shared

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Ian Lance Taylor
> Sent: 09 December 2004 20:32
> To: David Daney

> David Daney writes:
> 
> > I have code that generates stack traces that relies on the 
> structure of the
> > function prolog to work.  It looks for this:
> > 
> >         /*
> >          * Find function prolog.  It will have the form:
> >          *
> >          *	3c1c???? 	lui	gp,????
> >          *	279c???? 	addiu	gp,gp,????
> >          *	0399e021 	addu	gp,gp,t9
> >          *	27bd#### 	addiu	sp,sp,####
> >          *
> >          * Where ???? are the offset of the GOT from the function
> >          * entrypoint, and #### is the amount added to the 
> stack poiner.
> >          */
> > 
> > Your change will break it.
> 
> True, but only if you choose to use -mno-shared when you compile.  I'm
> not proposing that it be the default, only that it be an option.
> 
> Ian


  GDB will presumably barf on this too, won't it?  It does very much the same
kind of crude disassembling/parsing of function prologs IIUIC.

  Having said that, reversing the prolog to deduce information that was
discarded at compile-time is always going to be an inherently fragile strategy.
The proper solution (both for gdb and for David's application, and I think to
some extent gdb may be already beginning to support this where applicable) is to
compile the application with debug info that identifies which instructions are
prolog-related.  I think that means Dwarf-3.

  David, another thing that could break your code is if the MIPS gcc port starts
to use RTL prolog generation; when that happens, you'll start to see code where
instructions from the body of the function are migrated upward in among prolog
instructions by the scheduler.  That's liable to confuse any code that attempts
to parse prologs without using debug info. 

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: News MIPS option -mno-shared

[Thiemo Seufer]

Dave Korn wrote:
[snip]
>   David, another thing that could break your code is if the MIPS gcc port starts
> to use RTL prolog generation; when that happens, you'll start to see code where
> instructions from the body of the function are migrated upward in among prolog
> instructions by the scheduler.

FWIW, the o32 ABI IIRC requires the gpsetup to make up the first three
instructions of a function. I think for exactly the reasons discussed
before.


Thiemo

Re: News MIPS option -mno-shared

[Ian Lance Taylor]

Richard Sandiford <rsandifo@redhat.com> writes:

> OK.  I was just wondering if there was a specific reason for making
> .cpload (the o32 pseudo-op) use _gp but not .cpsetup (the n32 pseudo-op).
> I realise that most n32 code uses %hi/lo(%neg(%gp_rel(...))) directly,
> but some hand-written asm does use .cpsetup.

I just forgot about .cpsetup.  In the final patch I added support
there as well.

Ian

Re: News MIPS option -mno-shared

[David Daney]

Ian Lance Taylor wrote:
> I'd like to see whether anybody has an opinion about this patch before
> I check it in.
> 
> This patch adds a new option to the MIPS assembler: -mno-shared.
> Normally the .cpload pseudo-op generates code which looks like this:
> 
> 	lui	$gp,%hi(_gp_disp)
> 	addiu	$gp,$gp,%lo(_gp_disp)
> 	addu	$gp,$gp,.cpload argument
> 
> With -mno-shared, the .cpload pseudo-op will generate code that looks
> like this:
> 
> 	lui	$gp,%hi(_gp)
> 	addiu	$gp,$gp,%lo(_gp)
.
.
.
> Does anybody want to comment on this patch before I check it in?

I like this, but just one belated nit...

as --help says nothing about the new option.

David Daney