This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [m68k] Add uClinux-specific code generation options
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Pauli <pauli at moreton dot com dot au>
- Date: Thu, 11 Sep 2003 02:53:03 +0200
- Subject: Re: [m68k] Add uClinux-specific code generation options
- Organization: Develer S.r.l.
- References: <3F565FF3.7010602@develer.com> <20030903233127.GC3779@redhat.com>
Richard Henderson wrote:
On Wed, Sep 03, 2003 at 11:41:07PM +0200, Bernardo Innocenti wrote:
+#define LEA(sym,reg) movel a5@(_current_shared_library_a5_offset_),
I assume _current_shared_library_a5_offset_ is some sort of magic
assembler/linker symbol?
Yes. It's declared in a startup file provided by uClibc, and it's
initialized in a function called before main().
It should keep a pointer to the base of a special kind of GOT table
containing pointers to data and code sections of the program and its
shared libraries.
This black magic is required to get shared libraries to work
on systems without an MMU.
You might also consider using gas macros instead of cpp macros.
I find them more readable, since you don't have to use parenthesis.
Ok, I will. But can I do token pasting trickery with gas macros?
%{!mc68000:%{!m68000:%{!m68302:%{!m68010:%{!mc68020:%{!m68020:%{!m68030:%{!m68040:%{!m68020-40:%{!m68020-60:%{!m68060:%{!mcpu32: %{!m68332:%{!m5200:%{!m5206e:%{!m528x:%{!m5307:%{!m5407:%(cpp_cpu_default)}}}}}}}}}}}}}}}}}} \
+%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__}
Please convert all of this to use, as needed,
TARGET_CPU_CPP_BUILTINS
TARGET_OS_CPP_BUILTINS
TARGET_OBJFMT_CPP_BUILTINS
And please do that first.
This has already been done to some extent by Zack Weinberg's
cleanup patch.
Shall I move all the PIC definitions inside that
TARGET_CPU_CPP_BUILTINS in m68k.h?
+ /* Library identification */
+ if (m68k_library_id_string)
+ {
+ if (! TARGET_ID_SHARED_LIBRARY)
+ error ("-mshared-library-id= specified without -mid-shared-library");
+ m68k_library_id = atoi (m68k_library_id_string);
+ if (m68k_library_id < 0 || m68k_library_id > MAX_LIBRARY_ID)
+ error ("-mshared-library-id=%d is not between 0 and %d",
+ m68k_library_id, MAX_LIBRARY_ID);
+ }
+ else
+ m68k_library_id = -1;
[...]
+ if (m68k_library_id > 0)
+ {
+ asm_fprintf (stream, "\tmovel %s@(%d), %s\n",
+ reg_names[PIC_OFFSET_TABLE_REGNUM],
+ m68k_library_id * -4 - 4,
+ reg_names[PIC_OFFSET_TABLE_REGNUM]);
+ }
+ else
+ {
+ asm_fprintf (stream, "\tmovel
%s@(_current_shared_library_a5_offset_), %s\n",
+ reg_names[PIC_OFFSET_TABLE_REGNUM],
+ reg_names[PIC_OFFSET_TABLE_REGNUM]);
+ }
Consider doing
if (m68k_library_id_string)
{
// stuff, computing a new m68k_library_id_string with
// the proper decimal offset.
}
else
m68k_library_id_string = "_current_shared_library_a5_offset_";
asm_fprintf (stream, "\tmovel %s@(%s), %s\n",
reg_names[PIC_OFFSET_TABLE_REGNUM],
m68k_library_id_string,
reg_names[PIC_OFFSET_TABLE_REGNUM]);
Ok, will do it.
- if (! TARGET_68020 && flag_pic == 2)
+ if (!TARGET_68020 && !TARGET_COLDFIRE && (flag_pic == 2))
error("-fPIC is not currently supported on the 68000 or 68010\n");
Update the message if you're going to do that.
The message still seems valid to me. It should have included
the ColdFire in the list of unsupported -fPIC targets _before_
applying this patch ;-)
- if (flag_pic && current_function_uses_pic_offset_table)
+ if (! TARGET_SEP_DATA && flag_pic &&
+ (current_function_uses_pic_offset_table ||
+ ( ! current_function_is_leaf &&
Formatting.
Will fix.
+ { "hwdiv", MASK_CF_HWDIV, \
+ N_("Use hardware divisor") }, \
+ { "no-hwdiv", -MASK_CF_HWDIV, \
+ N_("Don't use hardware divisor") }, \
+ { "mac", 0, \
+ N_("Use hardware Multiply-accumulate unit") }, \
+ { "no-mac", 0, \
+ N_("Don't use hardware Multiply-accumulate unit") }, \
From some other patch, I assume.
Oops. Removed.
+/* The maximum alignment which the object file format can support. */
+#undef MAX_OFILE_ALIGNMENT
+#define MAX_OFILE_ALIGNMENT 128
Why is this in m68k.h?
Must have slipped in from the old patches I've collected.
I really don't know what it's for.
I'll remove it from this patch and see what happens. Perhaps it's
needed somewhere else by the uClinux target. In this case I'll move
it to the target specific header that is created by a still unsubmitted
patch.
+ /* We output a bsr instruction if we've using -fpic or we're
building for
+ * a target that supports long branches. If we're building -fPIC on
the
+ * 68000. 68010 or coldfire we're generate one of two sequences
+ * a shorter one that uses a GOT entry or a longer one that doesn't.
+ * We'll use the -Os commandline flag to decide which to generate.
+ * Both sequences take the same time to execute on the coldfire.
+ */
+ if (TARGET_SEP_DATA || TARGET_ID_SHARED_LIBRARY)
+ return \"move.l %0@GOT(%%a5), %%a1\\n\\tjsr (%%a1)\";
+ else if (TARGET_PCREL)
+ return \"bsr.l %o0\";
+ else if (flag_pic == 1 || TARGET_68020)
#ifdef HPUX_ASM
- return \"bsr.l %0\";
+ return \"bsr.l %0\";
#else
#ifdef USE_GAS
- return \"bsr.l %0@PLTPC\";
+ return \"bsr %0@PLTPC\";
#else
- return \"bsr %0@PLTPC\";
-#endif
-#endif
-#else
-#ifdef USE_GAS
- return \"bsr.l %0\";
-#else
- /* The ',a1' is a dummy argument telling the Sun assembler we want
PIC,
- GAS just plain ignores it. FIXME: not anymore, gas doesn't! */
- return \"jbsr %0,a1\";
+ return \"bsr.l %0@PLTPC\";
#endif
It'd be really nice if you moved this out of line to m68k.c,
so that we didn't have multiple copies of it.
Ok. Nice idea. And now that I look at it, the two copies are
even not synchronized. I fear one of them could be buggy.
--
// 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