[v6,01/16] sysdeps/init_array: Add PREINIT_FUNCTION to crti.S

Message ID 20180126054443.22702-2-palmer@dabbelt.com
State New, archived
Headers

Commit Message

Palmer Dabbelt Jan. 26, 2018, 5:44 a.m. UTC
  The RISC-V port contains a crti.S that simply contains a link to
PREINIT_FUNCTION (when defined).  As this should be entirely generic,
Joseph Myers suggested that we update the generic init_array version to
contain this.  Since RISC-V is the only user of init_array this won't
break any existing ports.

This uses '.section .init_array,"aw"', while pt-crti.S contains
'.section .init_array,"a",%init_array'.  I think we should include the
'%init_array' section type as well.  Additionally, I'm not sure about
the % vs @ distinction -- the gas documentation suggests that only ARM
uses '%', so maybe this generic directory should use '@' instead?  FWIW,
the RISC-V assembler appears to accept '%init_array' and '@init_array'.

2018-01-25  Palmer Dabbelt  <palmer@sifive.com>

        * sysdeps/init_array/crti.S (.section .init_array): Add
        PREINIT_FUNCTION when defined.
---
 sysdeps/init_array/crti.S | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
  

Comments

Joseph Myers Jan. 26, 2018, 12:21 p.m. UTC | #1
On Thu, 25 Jan 2018, Palmer Dabbelt wrote:

> This uses '.section .init_array,"aw"', while pt-crti.S contains
> '.section .init_array,"a",%init_array'.  I think we should include the
> '%init_array' section type as well.  Additionally, I'm not sure about

I think you should follow pt-crti.S exactly - using "a" not "aw" and using 
%init_array.  You also need to remove the #include of <sys/asm.h>, which 
is an architecture-specific header not available on most architectures.  
OK with those changes.

> the % vs @ distinction -- the gas documentation suggests that only ARM
> uses '%', so maybe this generic directory should use '@' instead?  FWIW,
> the RISC-V assembler appears to accept '%init_array' and '@init_array'.

% is valid everywhere.  @ is valid everywhere except platforms, such as 
ARM, that use @ as a comment character that can start comments in the 
middle of a line.  So in such an architecture-independent file, % is 
appropriate.
  
Palmer Dabbelt Jan. 26, 2018, 5:07 p.m. UTC | #2
On Fri, 26 Jan 2018 04:21:41 PST (-0800), joseph@codesourcery.com wrote:
> On Thu, 25 Jan 2018, Palmer Dabbelt wrote:
>
>> This uses '.section .init_array,"aw"', while pt-crti.S contains
>> '.section .init_array,"a",%init_array'.  I think we should include the
>> '%init_array' section type as well.  Additionally, I'm not sure about
>
> I think you should follow pt-crti.S exactly - using "a" not "aw" and using
> %init_array.  You also need to remove the #include of <sys/asm.h>, which
> is an architecture-specific header not available on most architectures.
> OK with those changes.
>
>> the % vs @ distinction -- the gas documentation suggests that only ARM
>> uses '%', so maybe this generic directory should use '@' instead?  FWIW,
>> the RISC-V assembler appears to accept '%init_array' and '@init_array'.
>
> % is valid everywhere.  @ is valid everywhere except platforms, such as
> ARM, that use @ as a comment character that can start comments in the
> middle of a line.  So in such an architecture-independent file, % is
> appropriate.

Thanks.  I've added a sort of TODO patch locally to my binutils tree to try to 
remind me to clarify the documentation.
  

Patch

diff --git a/sysdeps/init_array/crti.S b/sysdeps/init_array/crti.S
index 0a6e9fd95338..60ba071c1c6e 100644
--- a/sysdeps/init_array/crti.S
+++ b/sysdeps/init_array/crti.S
@@ -11,3 +11,19 @@ 
    But new configurations without compatibility concerns for
    toolchains without .init_array support can use this to avoid the
    superfluous .init and .fini boilerplate code.  */
+
+#include <sys/asm.h>
+
+#ifdef PREINIT_FUNCTION
+
+#if PREINIT_FUNCTION_WEAK
+# error PREINIT_FUNCTION_WEAK is unsupported
+#endif
+
+/* This arranges for PREINIT_FUNCTION to be called upon loading a library that
+   contains crti.o.  */
+
+	.section .init_array, "aw"
+	.dc.a PREINIT_FUNCTION
+
+#endif