* [arm] Use .init_array for static constructors.
@ 2004-09-24 1:11 Paul Brook
2004-09-24 19:08 ` Mark Mitchell
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Paul Brook @ 2004-09-24 1:11 UTC (permalink / raw)
To: gcc-patches; +Cc: Mark Mitchell, Richard Earnshaw
The following patch makes arm targets use the .init_array section for static
constructor lists. Non-eabi targets are unaffected. The pointers in this
section are relocated by relocated by an R_ARM_TARGET1 relocation.
The eabi doesn't provide a mecahnism for supporting the init_priority
attribute, so I've disables support for this on eabi based targets.
The eabi doesn't mention how static destructor lists should be handled, though
it's implied that the atexit functionality makes these unnecessary.
I've left the handling of .dtors unchanged.
Tested with cross to arm-none-elf and arm-none-eabi.
Ok for csl-arm-branch? mainline?
Paul
2004-09-23 Paul Brook <paul@codesourcery.com>
* config/arm/arm.c (arm_elf_asm_constructor): New function.
* config/arm/arm.h (CTORS_SECTION_ASM_OP): Define.
(CTORS_SECTION_FOR_TARGET, CTOR_LIST_END, CTOR_LIST_BEGIN): Define.
* config/arm/elf.h (TARGET_ASM_CONSTRUCTOR): Define.
(SUPPORTS_INIT_PRIORITY): Evaluate to false for EABI based targets.
Index: gcc/config/arm/arm.c
===================================================================
RCS file: /var/cvsroot/gcc-cvs/gcc/gcc/config/arm/arm.c,v
retrieving revision 1.303.2.53
diff -u -p -r1.303.2.53 arm.c
--- gcc/config/arm/arm.c 22 Sep 2004 15:40:28 -0000 1.303.2.53
+++ gcc/config/arm/arm.c 23 Sep 2004 18:14:13 -0000
@@ -144,6 +144,9 @@ static rtx arm_expand_unop_builtin (enum
static rtx arm_expand_builtin (tree, rtx, rtx, enum machine_mode, int);
static void emit_constant_insn (rtx cond, rtx pattern);
+#ifdef OBJECT_FORMAT_ELF
+static void arm_elf_asm_constructor (rtx, int);
+#endif
#ifndef ARM_PE
static void arm_encode_section_info (tree, rtx, int);
#endif
@@ -11036,6 +11039,26 @@ arm_assemble_integer (rtx x, unsigned in
return default_assemble_integer (x, size, aligned_p);
}
+
+
+/* Add a function to the list of static constructors. */
+
+static void
+arm_elf_asm_constructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
+{
+ if (!TARGET_AAPCS_BASED)
+ {
+ default_named_section_asm_out_constructor (symbol, priority);
+ return;
+ }
+
+ /* Put these in the .init_array section, using a special relocation. */
+ ctors_section ();
+ assemble_align (POINTER_SIZE);
+ fputs ("\t.word\t", asm_out_file);
+ output_addr_const (asm_out_file, symbol);
+ fputs ("(target1)\n", asm_out_file);
+}
#endif
\f
/* A finite state machine takes care of noticing whether or not instructions
Index: gcc/config/arm/arm.h
===================================================================
RCS file: /var/cvsroot/gcc-cvs/gcc/gcc/config/arm/arm.h,v
retrieving revision 1.210.2.41
diff -u -p -r1.210.2.41 arm.h
--- gcc/config/arm/arm.h 22 Sep 2004 15:40:30 -0000 1.210.2.41
+++ gcc/config/arm/arm.h 23 Sep 2004 18:14:13 -0000
@@ -2112,6 +2112,38 @@ typedef struct
#define ASM_OUTPUT_LABELREF(FILE, NAME) \
arm_asm_output_labelref (FILE, NAME)
+/* The EABI specifies that constructors should go in .init_array.
+ Other targets use .ctors for compatibility. */
+#undef CTORS_SECTION_ASM_OP
+#define CTORS_SECTION_ASM_OP (TARGET_AAPCS_BASED \
+ ? "\t.section\t.init_array,\"aw\",%init_array" \
+ : "\t.section\t.ctors,\"aw\",%progbits")
+
+/* There macros are used in target files. We need to define them here
+ because CTORS_SECTION_ASM_OP is not a constant. The code is identical
+ to the code in crtstuff.c, but duplicated here to avoid depending on
+ TARGET_AAPCS_BASED. */
+
+#ifdef __ARM_EABI__
+#define CTORS_SECTION_FOR_TARGET "\t.section\t.init_array,\"aw\",%init_array"
+#else
+#define CTORS_SECTION_FOR_TARGET "\t.section\t.ctors,\"aw\",%progbits"
+#endif
+
+#define CTOR_LIST_END \
+static func_ptr force_to_data[1] __attribute__ ((__unused__)) = { }; \
+asm (CTORS_SECTION_FOR_TARGET); \
+STATIC func_ptr __CTOR_END__[1] \
+ __attribute__((aligned(sizeof(func_ptr)))) \
+ = { (func_ptr) 0 };
+#define CTOR_LIST_BEGIN \
+static func_ptr force_to_data[1] __attribute__ ((__unused__)) = { }; \
+asm (CTORS_SECTION_FOR_TARGET); \
+STATIC func_ptr __CTOR_LIST__[1] \
+ __attribute__ ((__unused__, aligned(sizeof(func_ptr)))) \
+ = { (func_ptr) (-1) };
+
+
#define ARM_DECLARE_FUNCTION_SIZE(STREAM, NAME, DECL) \
arm_encode_call_attribute (DECL, SHORT_CALL_FLAG_CHAR)
Index: gcc/config/arm/elf.h
===================================================================
RCS file: /var/cvsroot/gcc-cvs/gcc/gcc/config/arm/elf.h,v
retrieving revision 1.44.8.5
diff -u -p -r1.44.8.5 elf.h
--- gcc/config/arm/elf.h 22 Sep 2004 15:40:30 -0000 1.44.8.5
+++ gcc/config/arm/elf.h 23 Sep 2004 18:14:13 -0000
@@ -124,6 +124,10 @@
#define TARGET_ASM_FILE_START_FILE_DIRECTIVE true
\f
+/* Output an element in the static constructor array. */
+#undef TARGET_ASM_CONSTRUCTOR
+#define TARGET_ASM_CONSTRUCTOR arm_elf_asm_constructor
+
/* For PIC code we need to explicitly specify (PLT) and (GOT) relocs. */
#define NEED_PLT_RELOC flag_pic
#define NEED_GOT_RELOC flag_pic
@@ -147,4 +151,5 @@
} \
while (0)
-#define SUPPORTS_INIT_PRIORITY 1
+/* The EABI doesn't provide a way of implementing init_priority. */
+#define SUPPORTS_INIT_PRIORITY (!TARGET_AAPCS_BASED)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [arm] Use .init_array for static constructors.
2004-09-24 1:11 [arm] Use .init_array for static constructors Paul Brook
@ 2004-09-24 19:08 ` Mark Mitchell
2004-09-25 23:26 ` Richard Henderson
2004-10-12 10:57 ` Richard Earnshaw
2 siblings, 0 replies; 4+ messages in thread
From: Mark Mitchell @ 2004-09-24 19:08 UTC (permalink / raw)
To: Paul Brook; +Cc: gcc-patches, Richard Earnshaw
Paul Brook wrote:
>The following patch makes arm targets use the .init_array section for static
>constructor lists. Non-eabi targets are unaffected. The pointers in this
>section are relocated by relocated by an R_ARM_TARGET1 relocation.
>The eabi doesn't provide a mecahnism for supporting the init_priority
>attribute, so I've disables support for this on eabi based targets.
>
>The eabi doesn't mention how static destructor lists should be handled, though
>it's implied that the atexit functionality makes these unnecessary.
>I've left the handling of .dtors unchanged.
>
>
There is still at least one way to get a static destructor:
void f() __attribute__((destructor));
in GNU C. (In C++, all static destructions should be registered with
atexit, as you say.)
I'm not sure what to do about that, though, if the ABI doesn't say.
>Tested with cross to arm-none-elf and arm-none-eabi.
>Ok for csl-arm-branch? mainline?
>
>
Looks good to me for csl-arm-branch. I think this should go on
mainline, too, but I think that an ARM maintainer should sign off first.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [arm] Use .init_array for static constructors.
2004-09-24 1:11 [arm] Use .init_array for static constructors Paul Brook
2004-09-24 19:08 ` Mark Mitchell
@ 2004-09-25 23:26 ` Richard Henderson
2004-10-12 10:57 ` Richard Earnshaw
2 siblings, 0 replies; 4+ messages in thread
From: Richard Henderson @ 2004-09-25 23:26 UTC (permalink / raw)
To: Paul Brook; +Cc: gcc-patches, Mark Mitchell, Richard Earnshaw
On Fri, Sep 24, 2004 at 12:47:20AM +0100, Paul Brook wrote:
> +#ifdef __ARM_EABI__
> +#define CTORS_SECTION_FOR_TARGET "\t.section\t.init_array,\"aw\",%init_array"
> +#else
> +#define CTORS_SECTION_FOR_TARGET "\t.section\t.ctors,\"aw\",%progbits"
> +#endif
> +
> +#define CTOR_LIST_END \
> +static func_ptr force_to_data[1] __attribute__ ((__unused__)) = { }; \
> +asm (CTORS_SECTION_FOR_TARGET); \
> +STATIC func_ptr __CTOR_END__[1] \
> + __attribute__((aligned(sizeof(func_ptr)))) \
> + = { (func_ptr) 0 };
> +#define CTOR_LIST_BEGIN \
> +static func_ptr force_to_data[1] __attribute__ ((__unused__)) = { }; \
> +asm (CTORS_SECTION_FOR_TARGET); \
> +STATIC func_ptr __CTOR_LIST__[1] \
> + __attribute__ ((__unused__, aligned(sizeof(func_ptr)))) \
> + = { (func_ptr) (-1) };
I don't think this change is right. In particular, it is Someone Else's
Job to run .init and .init_array. Usually, ld.so, but you may not have
one of those, in which case whoever runs .init now.
C.f. ia64 crtbegin.asm, in which .init_array is used, but to invoke
__do_global_ctors_aux, and not to run the individual constructors.
You *could* use .init_array instead of .ctors, but that's a different
and more extensive change than what you're presenting here.
r~
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [arm] Use .init_array for static constructors.
2004-09-24 1:11 [arm] Use .init_array for static constructors Paul Brook
2004-09-24 19:08 ` Mark Mitchell
2004-09-25 23:26 ` Richard Henderson
@ 2004-10-12 10:57 ` Richard Earnshaw
2 siblings, 0 replies; 4+ messages in thread
From: Richard Earnshaw @ 2004-10-12 10:57 UTC (permalink / raw)
To: Paul Brook; +Cc: gcc-patches, Mark Mitchell
On Fri, 2004-09-24 at 00:47, Paul Brook wrote:
> The eabi doesn't mention how static destructor lists should be handled, though
> it's implied that the atexit functionality makes these unnecessary.
> I've left the handling of .dtors unchanged.
The next draft does:
R_ARM_TARGET1 is processed in a platform-specific manner. It may
only be used in sections with the types SHT_INIT_ARRAY,
SHT_PREINIT_ARRAY, and SHT_FINI_ARRAY. The relocation must be
processed either in the same way as R_ARM_REL32 or as
R_ARM_ABS32: a virtual platform must specify which method is
used. If the relocation is processed as R_ARM_REL32 then the
section may be marked read-only and coalesced with other
read-only data, otherwise it may only be marked read-only if it
does not require dynamic linking.
However, you are right that this won't normally affect C++.
R.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-10-12 10:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-24 1:11 [arm] Use .init_array for static constructors Paul Brook
2004-09-24 19:08 ` Mark Mitchell
2004-09-25 23:26 ` Richard Henderson
2004-10-12 10:57 ` Richard Earnshaw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).