* [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
@ 2015-04-21 17:42 Petar Jovanovic
2015-04-21 18:52 ` Maciej W. Rozycki
0 siblings, 1 reply; 5+ messages in thread
From: Petar Jovanovic @ 2015-04-21 17:42 UTC (permalink / raw)
To: gcc-patches, Catherine_Moore, macro, Matthew.Fortune
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 } {
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
2015-04-21 17:42 [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro Petar Jovanovic
@ 2015-04-21 18:52 ` Maciej W. Rozycki
2015-04-22 15:42 ` Petar Jovanovic
0 siblings, 1 reply; 5+ messages in thread
From: Maciej W. Rozycki @ 2015-04-21 18:52 UTC (permalink / raw)
To: Petar Jovanovic; +Cc: gcc-patches, Catherine_Moore, Matthew.Fortune
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
2015-04-21 18:52 ` Maciej W. Rozycki
@ 2015-04-22 15:42 ` Petar Jovanovic
2015-04-23 14:55 ` Maciej W. Rozycki
0 siblings, 1 reply; 5+ messages in thread
From: Petar Jovanovic @ 2015-04-22 15:42 UTC (permalink / raw)
To: 'Maciej W. Rozycki'; +Cc: gcc-patches, Catherine_Moore, Matthew.Fortune
-----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
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
2015-04-22 15:42 ` Petar Jovanovic
@ 2015-04-23 14:55 ` Maciej W. Rozycki
2015-04-24 15:13 ` Petar Jovanovic
0 siblings, 1 reply; 5+ messages in thread
From: Maciej W. Rozycki @ 2015-04-23 14:55 UTC (permalink / raw)
To: Petar Jovanovic; +Cc: gcc-patches, Catherine_Moore, Matthew Fortune
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
2015-04-23 14:55 ` Maciej W. Rozycki
@ 2015-04-24 15:13 ` Petar Jovanovic
0 siblings, 0 replies; 5+ messages in thread
From: Petar Jovanovic @ 2015-04-24 15:13 UTC (permalink / raw)
To: 'Maciej W. Rozycki'
Cc: gcc-patches, Catherine_Moore, 'Matthew Fortune'
-----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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-04-24 15:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-21 17:42 [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro Petar Jovanovic
2015-04-21 18:52 ` Maciej W. Rozycki
2015-04-22 15:42 ` Petar Jovanovic
2015-04-23 14:55 ` Maciej W. Rozycki
2015-04-24 15:13 ` Petar Jovanovic
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).