[PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Petar Jovanovic]

New patch, v3. PTAL.

Regards,
Petar

gcc/ChangeLog:

2015-04-21  Petar Jovanovic  <petar.jovanovic@rt-rk.com>

	* config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro to
use
	la/jalr instead of jal.

gcc/testsuite/ChangeLog:

2015-04-21  Petar Jovanovic  <petar.jovanovic@rt-rk.com>

	* gcc.target/mips/call-from-init.c: New test.
	* gcc.target/mips/mips.exp: Add section_start to mips_option_groups.

commit 566564bd6d80fd6b5ebd6b8eccf09e3716246930
Author: Petar Jovanovic <petar.jovanovic@rt-rk.com>
Date:   Thu Jan 22 02:15:22 2015 +0100

    [mips] fix CRT_CALL_STATIC_FUNCTION macro
    
    jal can not reach a target in different region, so replace it with
    la/jalr variant.

diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index ec69ed5..4bd83f5 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -3034,11 +3034,11 @@ while (0)
 	nop\n\
 1:	.cpload $31\n\
 	.set reorder\n\
-	jal " USER_LABEL_PREFIX #FUNC "\n\
+	la $25, " USER_LABEL_PREFIX #FUNC "\n\
+	jalr $25\n\
 	.set pop\n\
 	" TEXT_SECTION_ASM_OP);
-#elif ((defined _ABIN32 && _MIPS_SIM == _ABIN32) \
-       || (defined _ABI64 && _MIPS_SIM == _ABI64))
+#elif (defined _ABIN32 && _MIPS_SIM == _ABIN32)
 #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)	\
    asm (SECTION_OP "\n\
 	.set push\n\
@@ -3048,7 +3048,22 @@ while (0)
 	nop\n\
 1:	.set reorder\n\
 	.cpsetup $31, $2, 1b\n\
-	jal " USER_LABEL_PREFIX #FUNC "\n\
+	la $25, " USER_LABEL_PREFIX #FUNC "\n\
+	jalr $25\n\
+	.set pop\n\
+	" TEXT_SECTION_ASM_OP);
+#elif (defined _ABI64 && _MIPS_SIM == _ABI64)
+#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)	\
+   asm (SECTION_OP "\n\
+	.set push\n\
+	.set nomips16\n\
+	.set noreorder\n\
+	bal 1f\n\
+	nop\n\
+1:	.set reorder\n\
+	.cpsetup $31, $2, 1b\n\
+	dla $25, " USER_LABEL_PREFIX #FUNC "\n\
+	jalr $25\n\
 	.set pop\n\
 	" TEXT_SECTION_ASM_OP);
 #endif
diff --git a/gcc/testsuite/gcc.target/mips/call-from-init.c
b/gcc/testsuite/gcc.target/mips/call-from-init.c
new file mode 100644
index 0000000..ee00a17
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/call-from-init.c
@@ -0,0 +1,10 @@
+/* Check that __do_global_ctors_aux can be reached from .init section that
+   is in a different (256MB) region. */
+/* { dg-do run } */
+/* { dg-options "-Wl,--section-start=.init=0x0FF00000" } */
+/* { dg-options "-Wl,--section-start=.text=0x10000000" } */
+
+int
+main (void) {
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
b/gcc/testsuite/gcc.target/mips/mips.exp
index a0980a9..1dd4173 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -254,6 +254,7 @@ set mips_option_groups {
     madd "HAS_MADD"
     maddps "HAS_MADDPS"
     lsa "(|!)HAS_LSA"
+    section_start "-Wl,--section-start=.*"
 }
 
 for { set option 0 } { $option < 32 } { incr option } {

Re: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Tue, 21 Apr 2015, Petar Jovanovic wrote:

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/mips/call-from-init.c
> @@ -0,0 +1,10 @@
> +/* Check that __do_global_ctors_aux can be reached from .init section that
> +   is in a different (256MB) region. */
> +/* { dg-do run } */
> +/* { dg-options "-Wl,--section-start=.init=0x0FF00000" } */
> +/* { dg-options "-Wl,--section-start=.text=0x10000000" } */

 Hmm, the addresses should work for any virtual-memory targets, however if 
this is going to be a run-time test, then not for bare-iron ones, as they 
won't normally support mapped addresses.  And we may not be able to come 
up with better ones, because a typical bare-iron target will often not 
have enough memory to span a 256MB boundary.  I think this will best be 
reduced to a link-only test on bare iron, hoping for a link failure.

 Speaking of which, have you been able to make a linker test case out of 
this example for a bug report against binutils?  Not necessarily a proper 
LD test suite addition, I wouldn't be asking for *that*!  Just a small 
case will do, e.g. a pair of .s files generated out of this source and the 
generated crtbegin.s file, preferably with unrelated clutter removed, 
together with a recipe how to assemble them and link to show the missing 
error message.  That will certainly help covering this issue all and for 
good!

 Thanks,

  Maciej

RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Petar Jovanovic]

-----Original Message-----
From: Maciej W. Rozycki [mailto:macro@linux-mips.org] 
Sent: Tuesday, April 21, 2015 8:52 PM
To: Petar Jovanovic
Cc: gcc-patches@gcc.gnu.org; Catherine_Moore@mentor.com;
Matthew.Fortune@imgtec.com
Subject: Re: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

> I think this will best be 
> reduced to a link-only test on bare iron, hoping for a link failure.

I am not sure how we can reduce the test to a link failure (today), if
ld will not report an error (today).
What exactly is wrong with the run time test as is in the last patch?

As of ld issue you have mentioned, it has been reported - see BZ#18297
[1].

Regards,
Petar

[1] BZ#18297, https://sourceware.org/bugzilla/show_bug.cgi?id=18297

RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Wed, 22 Apr 2015, Petar Jovanovic wrote:

> > I think this will best be 
> > reduced to a link-only test on bare iron, hoping for a link failure.
> 
> I am not sure how we can reduce the test to a link failure (today), if
> ld will not report an error (today).

 Me neither, offhand; hopefully someone is.

> What exactly is wrong with the run time test as is in the last patch?

 Addresses like 0x10000000 or 0x0FF00000 are in the KUSEG kernel/user 
segment address space.  They are mapped, that is translated through the 
TLB (the translation lookaside buffer, a small contents-addressed memory 
in the CPU that maps virtual addresses to physical ones).  A TLB refill 
exception will trigger when such an address is used for a data access or 
an instruction fetch.

 A proper OS that implements virtual memory management will then handle it 
and use its page tables to refill the TLB and restart the faulting 
instruction that will usually succeed.  Further exceptions may follow if 
e.g. the page has been marked absent and has to be pulled first from swap 
or from a file it has been mmap(2)ed from, or a copy-on-write page has 
been marked read-only and a copy needs to be made on the first write, etc. 
and the OS will handle them one by one.

 In a bare-iron environment there's usually no virtual memory management, 
so a TLB refill exception will result in a crash.  Or a hang.  Either way 
the test case will fail, and sometimes it will take long to time out.  On 
the MIPS processor bare-iron programs will usually use unmapped addresses 
that have a fixed association with corresponding physical addresses and as 
such bypass the TLB.  These will usually be ones in the KSEG0 (on 32-bit 
targets) or the XKPHYS (on 64-bit targets) kernel segments.

 For example 0x90000000 and 0x8FF00000 would be KSEG0 addresses suitable 
for your test case, that map to 0x10000000 and 0x0FFF0000 physical 
addresses respectively.  As the mapping is fixed, you need to make sure 
there is actual memory across the 256MB boundary spanned here.

 Also these addresses will not work for a user program[*], such as under 
Linux, as the kernel segments, as the name implies, can only be referred 
to in the kernel mode.  Consequently an Address Error exception will 
trigger and the kernel will kill the user process that misbehaved.  If 
such addresses are used to lay out an executable, in ELF file's segment 
headers, then the kernel will refuse to run it in the first place.

 I hope you find this explanation satisfactory, however if you still find 
anything unclear or have any other questions or concerns, then please 
shout.

 BTW, can you please change 0x0FF00000 to 0x0FFF0000 or suchlike to avoid 
making the executable larger than absolutely necessary, or is 0x0FF00000 
actually required due to section/segment alignment constraints?  You 
didn't mention in your patch description why you picked up these 
particular addresses.

[*] Recently addresses in the 32-bit 0x80000000-0xbfffffff address space 
    have been enabled for user access with the use of the EVA (enhanced 
    virtual addressing) mode.  This mode is not universally supported 
    across hardware or OS software though and is still an exception rather 
    than a norm so we cannot assume it will be available.

> As of ld issue you have mentioned, it has been reported - see BZ#18297
> [1].

 Thanks, I've added myself as a watcher and will see what I can do about 
it.  Unless someone else beats me to it, that is.

  Maciej

RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Petar Jovanovic]

-----Original Message-----
From: Maciej W. Rozycki [mailto:macro@linux-mips.org] 
Sent: Thursday, April 23, 2015 4:55 PM
To: Petar Jovanovic
Cc: gcc-patches@gcc.gnu.org; Catherine_Moore@mentor.com; Matthew Fortune
Subject: RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

>  I hope you find this explanation satisfactory, however if you still find 
> anything unclear or have any other questions or concerns, then please 
> shout.

Hi Maciej,

Thank you for your response. I should have coined my question better
though, so you do not need to write it all. In the v4 patch, I have
skipped the test for bare iron targets.

>  BTW, can you please change 0x0FF00000 to 0x0FFF0000 or suchlike to avoid 
> making the executable larger than absolutely necessary

Done.

> You didn't mention in your patch description why you picked up these
particular addresses.

There is a comment in the test which indicates that. I have put it as
part of the commit message now as well.

Regards,
Petar