OpenRISC port

+ l.sfeqi r4, 0 /* division by zero; return 0. */

+/* For signed division we do:
+ *

+ *   -x / y = x / -y = -(x / y)
+ *   -x % y = -(x % y)
+ *   x % -y = x % b

+ *
+ * which has the property that (x/y)*y + (x%y) = x.
+ */

Hi!

libgcc/config/or1k/lib1funcs.S line 33

Quoted 4 lines · Stafford Horne

libgcc/config/or1k/lib1funcs.S new file +4 -0

+	/* Given R = X * Y ... */
+1:	l.sfeq		r4, r0			/* while (y != 0) */
+	l.bf		2f
+	 l.andi		r5, r4, 1		/* if (y & 1) ... */

Do the extra leading spaces mean something?

Quoted 1 line

+ l.sfeqi r4, 0 /* division by zero; return 0. */

In some places (like here) you ident with 8 spaces instead of a tab.

Quoted 8 lines

+/* For signed division we do:
+ *

+ *   -x / y = x / -y = -(x / y)
+ *   -x % y = -(x % y)
+ *   x % -y = x % b

+ *
+ * which has the property that (x/y)*y + (x%y) = x.
+ */

You mean "y" instead of "b" I think.

libgcc/config/or1k/lib1funcs.S new file +4 -0

+	/* Shift Y back to the right again, subtracting from X.  */
+2:	l.add		r7, r11, r6	/* tmp1 = quot + mask */
+3:	l.srli		r6, r6, 1	/* mask >>= 1 */
+	l.sub		r8, r12, r4	/* tmp2 = x - y */

libgcc/config/or1k/crti.S line 33

Quoted 12 lines · Stafford Horne

libgcc/config/or1k/crti.S new file +12 -0

+/* Here _init and _fini are empty because .init_array/.fini_array are used
+   exclusively.  However, the functions are still needed as required when
+   linking.  */
+	.align 4
+	.global	_init
+	.type	_init, at function
+_init:
+	.global	_fini
+	.type	_fini, at function
+_fini:
+	l.jr	r9
+	 l.nop

Where are they referenced from? Perhaps just a binutils bug, in that the linker script needs adjustment?

libgcc/config/or1k/lib1funcs.S line 42

Quoted 13 lines

libgcc/config/or1k/lib1funcs.S new file +13 -0

+	/* Given R = X * Y ... */
+1:	l.sfeq		r4, r0			/* while (y != 0) */
+	l.bf		2f
+	 l.andi		r5, r4, 1		/* if (y & 1) ... */
+	l.add		r12, r11, r3
+	l.sfne		r5, r0
+#if defined(__or1k_cmov__)
+	l.cmov		r11, r12, r11		/* ... r += x. */
+	l.srli		r4, r4, 1		/* y >>= 1 */
+#else
+	l.bnf		3f
+	 l.srli		r4, r4, 1		/* y >>= 1 */
+	l.ori		r11, r12, 0

This move could be the add to save 1 cycle in the !cmov case.

Quoted 4 lines

libgcc/config/or1k/lib1funcs.S new file +4 -0

+	/* Shift Y back to the right again, subtracting from X.  */
+2:	l.add		r7, r11, r6	/* tmp1 = quot + mask */
+3:	l.srli		r6, r6, 1	/* mask >>= 1 */
+	l.sub		r8, r12, r4	/* tmp2 = x - y */

libgcc/config/or1k/lib1funcs.S line 98

Quoted 10 lines

libgcc/config/or1k/lib1funcs.S new file +10 -0

+	l.sfleu		r4, r12		/* y <= x */
+	l.srli		r4, r4, 1	/* y >>= 1 */
+#if defined(__or1k_cmov__)
+	l.cmov		r11, r7, r11	/* if (y <= x) quot = tmp1 */
+	l.cmov		r12, r8, r12	/* if (y <= x) x = tmp2 */
+#else
+	l.bnf		4f
+	 l.nop
+	l.ori		r11, r7, 0
+	l.ori		r12, r8, 0

Simiarly.

Although both mul nor div are correct as-is, and need not be fixed immediately.
I'm only concerned about _init and _fini.

yyyy-mm-dd Stafford Horne <[email protected]>
Richard Henderson <[email protected]>

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/20101011-1.c: Adjust for OpenRISC.
* gcc.dg/20020312-2.c: Likewise.
* gcc.dg/attr-alloc_size-11.c: Likewise.
* gcc.dg/builtin-apply2.c: Likewise.
* gcc.dg/nop.h: Likewise.
* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise.
* gcc.dg/tree-ssa/20040204-1.c: Likewise.
* gcc.dg/tree-ssa/reassoc-33.c: Likewise.
* gcc.dg/tree-ssa/reassoc-34.c: Likewise.
* gcc.dg/tree-ssa/reassoc-35.c: Likewise.
* gcc.dg/tree-ssa/reassoc-36.c: Likewise.
* lib/target-supports.exp (check_effective_target_logical_op_short_circuit): Add or1k*-*-*.
* gcc.target/or1k/*: New.
---

gcc/config/or1k/or1k.md new file +7 -0

+(define_insn "zero_extendhisi2"
+  [(set (match_operand:SI 0 "register_operand"                    "=r,r")
+	(zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "r,m")))]
+  ""
+  "@
+   l.exthz\t%0, %1
+   l.lhz\t%0, %1"

gcc/config/or1k/or1k.md new file +10 -0

+;; Sign extension patterns
+
+;; We can do memory extensions with a single load
+(define_insn "extendhisi2"
+  [(set (match_operand:SI 0 "register_operand"                     "=r,r")
+	(sign_extend:SI (match_operand:HI 1 "nonimmediate_operand"  "r,m")))]
+  ""
+  "@
+   l.exths\t%0, %1
+   l.lhs\t%0, %1"

Quoted 11 lines · Stafford Horne

gcc/config/or1k/or1k.md new file +11 -0

+(define_insn "zero_extendhisi2"
+  [(set (match_operand:SI 0 "register_operand"                    "=r,r")
+	(zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "r,m")))]
+  ""
+  "@
+   l.exthz\t%0, %1
+   l.lhz\t%0, %1"
+  [(set_attr "insn_support" "sext,*")])
+
+(define_insn "zero_extendqisi2"
+  [(set (match_operand:SI 0 "register_operand"                    "=r,r")

gcc/config/or1k/or1k.md line 346

Quoted 6 lines

gcc/config/or1k/or1k.md new file +6 -0

+	(zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "r,m")))]
+  ""
+  "@
+   l.extbz\t%0, %1
+   l.lbz\t%0, %1"
+  [(set_attr "insn_support" "sext,*")])

The !sext r/r case is just l.andi.

Quoted 16 lines

gcc/config/or1k/or1k.md new file +16 -0

+;; Sign extension patterns
+
+;; We can do memory extensions with a single load
+(define_insn "extendhisi2"
+  [(set (match_operand:SI 0 "register_operand"                     "=r,r")
+	(sign_extend:SI (match_operand:HI 1 "nonimmediate_operand"  "r,m")))]
+  ""
+  "@
+   l.exths\t%0, %1
+   l.lhs\t%0, %1"
+  [(set_attr "insn_support" "sext,*")])
+
+(define_insn "extendqisi2"
+  [(set (match_operand:SI 0 "register_operand"                     "=r,r")
+	(sign_extend:SI (match_operand:QI 1 "nonimmediate_operand"  "r,m")))]
+  ""

gcc/config/or1k/or1k.md line 367

Quoted 4 lines

gcc/config/or1k/or1k.md new file +4 -0

+  "@
+   l.extbs\t%0, %1
+   l.lbs\t%0, %1"
+  [(set_attr "insn_support" "sext,*")])

You don't really want to give the register allocator no choice but to spill to memory in the !sext case. Another r/r case with a splitter that is conditional on !sext would work.

Otherwise, OK.

OK, I was just being lazy allowing the spill. Do you think the split/expand would be an RTL using left shift / right shift? Can you think of something more clever? Since "real" hardware does not usually support shifts with an immediate we will need 1 instruction to load shift amount. i.e.

l.ori %0, r0, 24
l.sll %1, %1, %0
l.sra %0, %1, %0

I am submitting patches on my git branch or1k-port-4. Just in case you want to track progress.

Quoted 8 lines · Stafford Horne

OK, I was just being lazy allowing the spill. Do you think the split/expand would be an RTL using left shift / right shift? Can you think of something more clever? Since "real" hardware does not usually support shifts with an immediate we will need 1 instruction to load shift amount. i.e.

l.ori %0, r0, 24
l.sll %1, %1, %0
l.sra %0, %1, %0

This clobbers %1.

So, ouch. I think we will want to avoid creating this particular pattern in the first place unless l.exts exists then. We would use another pattern like

(define_insn "*sign_extend_mem<mode>"
[(set (match_operand:SI 0 "register_operand" "=r")

	(sign_extend:SI
	  (match_operand:HI 1 "memory_operand" "m")))]

""
"l.lhs\t%0, %1")

following the TARGET_SEXT pattern. In this way combine can use this pattern without getting us into trouble with the register allocator later.

+ /* Number of bytes saved on the stack for outgoing/sub-fucntion args. */

+ /* Set address to volitile to ensure the store doesn't get optimized out. */

+ split. Symbols are lagitimized using split relocations. */

+#define WCHAR_TYPE_SIZE 32

+#define FUNCTION_ARG_REGNO_P(r) (r >= 3 && r <= 8)

+ { ARG_POINTER_REGNUM, STACK_POINTER_REGNUM }, \

+#define EH_RETURN_REGNUM HW_TO_GCC_REGNO (23)

Hi Stafford,

Some minor comments. I didn't read the atomics much, but I did look at everything else, and it looks fine :-)

gcc/config.gcc nvptx-*) · line 2501

Quoted 5 lines · Stafford Horne

gcc/config.gcc +5 -0

+        case ${target} in
+        or1k*-*-linux*)
+                tm_file="${tm_file} gnu-user.h linux.h glibc-stdint.h"
+                tm_file="${tm_file} or1k/linux.h"
+                ;;

Spaces instead of tabs.

Quoted 1 line

+ /* Number of bytes saved on the stack for outgoing/sub-fucntion args. */

Typo ("function").

gcc/config/or1k/or1k.c line 71

Quoted 3 lines

gcc/config/or1k/or1k.c new file +3 -0

+  /* The sum of sizes: locals vars, called saved regs, stack pointer
+   * and an optional frame pointer.
+   * Used in expand_prologue () and expand_epilogue().  */

We don't use leading stars in comments (just spaces), normally.

Quoted 1 line

+ /* Set address to volitile to ensure the store doesn't get optimized out. */

"volatile"

gcc/config/or1k/or1k.c line 514

Quoted 9 lines

gcc/config/or1k/or1k.c new file +9 -0

+/* Helper for defining INITIAL_ELIMINATION_OFFSET.
+   We allow the following eliminiations:
+     FP -> HARD_FP or SP
+     AP -> HARD_FP or SP
+
+   HFP and AP are the same which is handled below.  */
+
+HOST_WIDE_INT
+or1k_initial_elimination_offset (int from, int to)

You could calculate this as some_offset (from) - some_offset (to) with some_offset a simple helper function. That gives you all possible eliminations :-)

(Each offset is very cheap to compute in your case, so that's not a problem).

gcc/config/or1k/or1k.c line 961

Quoted 4 lines

gcc/config/or1k/or1k.c new file +4 -0

+static rtx
+or1k_function_value (const_tree valtype,
+		     const_tree fn_decl_or_type ATTRIBUTE_UNUSED,
+		     bool outgoing ATTRIBUTE_UNUSED)

Since we use C++ now you can write this as

		     bool /*outgoing*/)

or such, for enhanced readability.

Quoted 1 line

+ split. Symbols are lagitimized using split relocations. */

"legitimized"

gcc/config/or1k/or1k.c line 1387

Quoted 6 lines

gcc/config/or1k/or1k.c new file +6 -0

+void
+or1k_expand_move (machine_mode mode, rtx op0, rtx op1)
+{
+  if (MEM_P (op0))
+    {
+      if (!const0_operand(op1, mode))

Space before (.

gcc/config/or1k/or1k.c line 1589

Quoted 2 lines

gcc/config/or1k/or1k.c new file +2 -0

+#undef TARGET_RTX_COSTS
+#define TARGET_RTX_COSTS or1k_rtx_costs

You may want TARGET_INSN_COST as well (it is easier to get (more) correct).

gcc/config/or1k/or1k.c line 2088

Quoted 6 lines

gcc/config/or1k/or1k.c new file +6 -0

+      if (hi != 0)
+	{
+	  rtx scratch2 = gen_rtx_REG (Pmode, RV_REGNUM);
+	  emit_move_insn (scratch2, GEN_INT (hi));
+	  emit_insn (gen_add2_insn (scratch, scratch2));
+        }

Tab instead of spaces.

gcc/config/or1k/or1k.c line 2100

Quoted 2 lines

gcc/config/or1k/or1k.c new file +2 -0

+  /* Generate a tail call to the target function.  */
+  if (! TREE_USED (function))

No space after !.

gcc/config/or1k/or1k.c line 2164

Quoted 3 lines

gcc/config/or1k/or1k.c new file +2 -0

+#define TARGET_RETURN_IN_MEMORY	or1k_return_in_memory
 
+#define	TARGET_PASS_BY_REFERENCE or1k_pass_by_reference

These two have a tab instead of a space (as the rest do).

Quoted 1 line

+#define WCHAR_TYPE_SIZE 32

And this.

gcc/config/or1k/or1k.h line 126

Quoted 6 lines

gcc/config/or1k/or1k.h new file +6 -0

+   This ABI has no adjacent call-saved register, which means that
+   DImode/DFmode pseudos cannot be call-saved and will always be
+   spilled across calls.  To solve this without changing the ABI,
+   remap the compiler internal register numbers to place the even
+   call-saved registers r16-r30 in 24-31, and the odd call-clobbered
+   registers r17-r31 in 16-23.  */

Ooh evilness :-)

gcc/config/or1k/or1k.h line 291

Quoted 2 lines

gcc/config/or1k/or1k.h new file +2 -0

+#define Pmode	SImode
+#define FUNCTION_MODE	SImode

Some more tabs.

Quoted 1 line

+#define FUNCTION_ARG_REGNO_P(r) (r >= 3 && r <= 8)

IN_RANGE ?

Quoted 1 line

+ { ARG_POINTER_REGNUM, STACK_POINTER_REGNUM }, \

Weird tab here, too.

Quoted 1 line

+#define EH_RETURN_REGNUM HW_TO_GCC_REGNO (23)

And here.

gcc/config/or1k/or1k.md line 206

Quoted 9 lines

gcc/config/or1k/or1k.md new file +9 -0

+(define_insn "xorsi3"
+  [(set (match_operand:SI 0 "register_operand" "=r,r")
+	  (xor:SI
+	   (match_operand:SI 1 "register_operand"   "%r,r")
+	   (match_operand:SI 2 "reg_or_s16_operand" " r,I")))]
+  ""
+  "@
+  l.xor\t%0, %1, %2
+  l.xori\t%0, %1, %2")

Is this correct? Should this be unsigned (u16 and K)?
https://sourceware.org/cgen/gen-doc/openrisc-insn.html suggest so, but I don't know how up-to-date or relevant that is. Well. From the atomics much below it seems to be correct, and signed is nice for making a bit inverse. Is there some better documentation? Something to put at
https://gcc.gnu.org/readings.html (this is in the CVS repo, still see
https://gcc.gnu.org/about.html#cvs ).

gcc/config/or1k/or1k.md line 235

Quoted 3 lines

gcc/config/or1k/or1k.md new file +3 -0

+(define_expand "mov<I:mode>"
+  [(set (match_operand:I 0 "nonimmediate_operand" "")
+	(match_operand:I 1 "general_operand" ""))]

You can completely leave out empty constraint strings, for example in the expanders.

gcc/config/or1k/or1k.opt line 32

Quoted 7 lines

gcc/config/or1k/or1k.opt new file +7 -0

+mhard-div
+Target RejectNegative InverseMask(SOFT_DIV)
+Use hardware divide instructions, use -msoft-div for emulation.
+
+mhard-mul
+Target RejectNegative InverseMask(SOFT_MUL).
+Use hardware multiply instructions, use -msoft-mul for emulation.

Maybe put the -msoft-* options near here then?

This was a lovely read. Thank you! Your port looks great.

Quoted 14 lines · Segher Boessenkool

gcc/config/or1k/or1k.c line 514

Quoted 9 lines

gcc/config/or1k/or1k.c new file +9 -0

+/* Helper for defining INITIAL_ELIMINATION_OFFSET.
+   We allow the following eliminiations:
+     FP -> HARD_FP or SP
+     AP -> HARD_FP or SP
+
+   HFP and AP are the same which is handled below.  */
+
+HOST_WIDE_INT
+or1k_initial_elimination_offset (int from, int to)

You could calculate this as some_offset (from) - some_offset (to) with some_offset a simple helper function. That gives you all possible eliminations :-)

Quoted 1 line

(Each offset is very cheap to compute in your case, so that's not a problem).

Right, Do you mean something like the following? I think it would work, but I am not sure it make the code easier to read. Do you think there would be much benefits supporting all possible eliminations?

Quoted 4 lines

gcc/config/or1k/or1k.c line 1589

Quoted 2 lines

gcc/config/or1k/or1k.c new file +2 -0

+#undef TARGET_RTX_COSTS
+#define TARGET_RTX_COSTS or1k_rtx_costs

You may want TARGET_INSN_COST as well (it is easier to get (more) correct).

OK, I was not considering that for the first port. Perhaps after getting this in? I think in general the OpenRISC insruction costs are fairly flat for the ones are using.

Quoted 8 lines

gcc/config/or1k/or1k.h line 126

Quoted 6 lines

gcc/config/or1k/or1k.h new file +6 -0

+   This ABI has no adjacent call-saved register, which means that
+   DImode/DFmode pseudos cannot be call-saved and will always be
+   spilled across calls.  To solve this without changing the ABI,
+   remap the compiler internal register numbers to place the even
+   call-saved registers r16-r30 in 24-31, and the odd call-clobbered
+   registers r17-r31 in 16-23.  */

Ooh evilness :-)

Richard did this, I thought it was rather clever. :)

Quoted 3 lines

Quoted 1 line

+#define FUNCTION_ARG_REGNO_P(r) (r >= 3 && r <= 8)

IN_RANGE ?

OK, I may change it, I think without the macro, its easy to understand that its (inclusive).

Hi!

Quoted 15 lines · Stafford Horne

Quoted 14 lines · Segher Boessenkool

gcc/config/or1k/or1k.c line 514

Quoted 9 lines

gcc/config/or1k/or1k.c new file +9 -0

+/* Helper for defining INITIAL_ELIMINATION_OFFSET.
+   We allow the following eliminiations:
+     FP -> HARD_FP or SP
+     AP -> HARD_FP or SP
+
+   HFP and AP are the same which is handled below.  */
+
+HOST_WIDE_INT
+or1k_initial_elimination_offset (int from, int to)

You could calculate this as some_offset (from) - some_offset (to) with some_offset a simple helper function. That gives you all possible eliminations :-)

Quoted 5 lines

Quoted 1 line

(Each offset is very cheap to compute in your case, so that's not a problem).

Right, Do you mean something like the following? I think it would work, but I am not sure it make the code easier to read. Do you think there would be much benefits supporting all possible eliminations?

Yes, like that. It also easily can handle the other combos (those with STACK_POINTER), and it is easier if you have to switch FRAME_GROWS_DOWNWARD ("false" is better on some args, but "true" is required for ssp).

Your code is fine as-is of course.

Hello,

Quoted 4 lines · Segher Boessenkool

Yes, like that. It also easily can handle the other combos (those with STACK_POINTER), and it is easier if you have to switch FRAME_GROWS_DOWNWARD ("false" is better on some args, but "true" is required for ssp).

Quoted 1 line

Your code is fine as-is of course.

Just to be clear, when you say 'as-is' did you mean the original v3 patch? Or are you referring to followup patch I posted with the some_offset (from) - some_offset (to) logic.

Quoted 7 lines · Stafford Horne

Hello,

Quoted 4 lines · Segher Boessenkool

Yes, like that. It also easily can handle the other combos (those with STACK_POINTER), and it is easier if you have to switch FRAME_GROWS_DOWNWARD ("false" is better on some args, but "true" is required for ssp).

Quoted 5 lines

Quoted 1 line

Your code is fine as-is of course.

Just to be clear, when you say 'as-is' did you mean the original v3 patch? Or are you referring to followup patch I posted with the some_offset (from) - some_offset (to) logic.

Either. Both. I meant the orig big patch, v3 if that's what it was.

Quoted 10 lines · Segher Boessenkool

Quoted 9 lines · Stafford Horne

Hello,

Quoted 5 lines · Segher Boessenkool

Yes, like that. It also easily can handle the other combos (those with STACK_POINTER), and it is easier if you have to switch FRAME_GROWS_DOWNWARD ("false" is better on some args, but "true" is required for ssp).

Your code is fine as-is of course.

Quoted 5 lines

Quoted 3 lines

Just to be clear, when you say 'as-is' did you mean the original v3 patch? Or are you referring to followup patch I posted with the some_offset (from) - some_offset (to) logic.

Either. Both. I meant the orig big patch, v3 if that's what it was.

Alright, thanks, I just didnt want to misunderstand.

gcc/config/or1k/or1k.md line 206

Quoted 9 lines

gcc/config/or1k/or1k.md new file +9 -0

+(define_insn "xorsi3"
+  [(set (match_operand:SI 0 "register_operand" "=r,r")
+	  (xor:SI
+	   (match_operand:SI 1 "register_operand"   "%r,r")
+	   (match_operand:SI 2 "reg_or_s16_operand" " r,I")))]
+  ""
+  "@
+  l.xor\t%0, %1, %2
+  l.xori\t%0, %1, %2")

Is this correct? Should this be unsigned (u16 and K)?

Quoted 11 lines · Segher Boessenkool

gcc/config/or1k/or1k.md line 206

Quoted 9 lines

gcc/config/or1k/or1k.md new file +9 -0

+(define_insn "xorsi3"
+  [(set (match_operand:SI 0 "register_operand" "=r,r")
+	  (xor:SI
+	   (match_operand:SI 1 "register_operand"   "%r,r")
+	   (match_operand:SI 2 "reg_or_s16_operand" " r,I")))]
+  ""
+  "@
+  l.xor\t%0, %1, %2
+  l.xori\t%0, %1, %2")

Is this correct? Should this be unsigned (u16 and K)?

No, l.xori is signed.

Quoted 3 lines · Richard Henderson

Quoted 1 line · Segher Boessenkool

Is this correct? Should this be unsigned (u16 and K)?

Quoted 1 line

No, l.xori is signed.

Right, sorry, I didn't have enough time to look at this at all this morning. It is correct.

It looks like the documentation for this page [1] is generated from the cgen cpu descriptions that were removed from binutils-gdb back in 2014. Ccing cgen who seem to maintain this web page. How can we go about getting it regenerated?

Is there some better documentation available? This is what google found for me. I would have like better docs (more compact, etc.) Links to such would be great to have in readings.html :-)

Quoted 3 lines · Segher Boessenkool

Is there some better documentation available? This is what google found for me. I would have like better docs (more compact, etc.) Links to such would be great to have in readings.html :-)

https://openrisc.io/architecture

and especially the v1.2 pdf linked from there

https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.2-rev0.pdf

Quoted 9 lines · Richard Henderson

Quoted 3 lines · Segher Boessenkool

Is there some better documentation available? This is what google found for me. I would have like better docs (more compact, etc.) Links to such would be great to have in readings.html :-)

https://openrisc.io/architecture

and especially the v1.2 pdf linked from there

Quoted 1 line

https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.2-rev0.pdf

Thanks,

I meant to point this out during my previous reply. Also, I will send a patch for adding this to wwwdocs.

https://www.gnu.org/software/gcc/readings.html

+++ b/gcc/config/or1k/linux.h

gcc/config/or1k/linux.h new file +34 -0

@@ -0,0 +1,44 @@
+/* Linux Definitions for OpenRISC.
+   Copyright (C) 2018 Free Software Foundation, Inc.
+   Contributed by Stafford Horne.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   <http://www.gnu.org/licenses/>.  */
+
+#ifndef GCC_OR1K_LINUX_H
+#define GCC_OR1K_LINUX_H
+
+/* elfos.h should have already been included.  Now just override
+   any conflicting definitions and add any extras.  */
+
+#define TARGET_OS_CPP_BUILTINS() \
+  GNU_USER_TARGET_OS_CPP_BUILTINS ()
+
+#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-or1k.so.1"
+
+#undef MUSL_DYNAMIC_LINKER
+#define MUSL_DYNAMIC_LINKER  "/lib/ld-musl-or1k.so.1"
+

Quoted 41 lines · Stafford Horne

+++ b/gcc/config/or1k/linux.h

(quoted diff) +39 -0

@@ -0,0 +1,44 @@
+/* Linux Definitions for OpenRISC.
+   Copyright (C) 2018 Free Software Foundation, Inc.
+   Contributed by Stafford Horne.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   <http://www.gnu.org/licenses/>.  */
+
+#ifndef GCC_OR1K_LINUX_H
+#define GCC_OR1K_LINUX_H
+
+/* elfos.h should have already been included.  Now just override
+   any conflicting definitions and add any extras.  */
+
+#define TARGET_OS_CPP_BUILTINS() \
+  GNU_USER_TARGET_OS_CPP_BUILTINS ()
+
+#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-or1k.so.1"
+
+#undef MUSL_DYNAMIC_LINKER
+#define MUSL_DYNAMIC_LINKER  "/lib/ld-musl-or1k.so.1"
+
+#undef LINK_SPEC
+#define LINK_SPEC "%{h*}			\
+   %{static:-Bstatic}				\
+   %{shared:-shared}				\
+   %{symbolic:-Bsymbolic}			\

Review line 44

Quoted 5 lines

(quoted diff) +5 -0

+   %{!static:					\
+     %{rdynamic:-export-dynamic}		\
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+
+#endif /* GCC_OR1K_LINUX_H */

note that because of the -static-pie mess each target needs a more complicated LINK_SPEC now.

i think there could be a generic LINK_SPEC in config/linux.h or config/gnu-user.h that works for simple targets (the start file spec is already there) so this complex logic is not repeated everywhere.

or even do the -no-dynamic-linker logic in LINK_PIE_SPEC in gcc.c for all targets, not just linux, so backends don't need to do anything to get static-pie to work.

Quoted 1 line · Szabolcs Nagy

On 27/10/18 05:37, Stafford Horne wrote:

Quoted 5 lines

Quoted 5 lines

(quoted diff) +5 -0

+#undef LINK_SPEC
+#define LINK_SPEC "%{h*}			\
+   %{static:-Bstatic}				\
+   %{shared:-shared}				\
+   %{symbolic:-Bsymbolic}			\

Quoted 8 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+   %{!static:					\
+     %{rdynamic:-export-dynamic}		\
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+
+#endif /* GCC_OR1K_LINUX_H */

note that because of the -static-pie mess each
target needs a more complicated LINK_SPEC now.

Hello,

Does something like this look better?

gcc/config/or1k/linux.h +0 -0

@@ -37,8 +37,9 @@
    %{static:-Bstatic}                          \

I have tested this out with or1k-linux-musl, but I get some LD complaints i.e.

.../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_end .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_start

Those are some warnings we recently added to LD, perhaps I need to rebuild the libc.a with PIE as well. I will try it out, but if anyone has some suggestions that would be helpful.

Quoted 2 lines · Stafford Horne

Quoted 1 line · Szabolcs Nagy

On 27/10/18 05:37, Stafford Horne wrote:

...

Quoted 22 lines

Quoted 5 lines

Quoted 5 lines

(quoted diff) +5 -0

+#undef LINK_SPEC
+#define LINK_SPEC "%{h*}			\
+   %{static:-Bstatic}				\
+   %{shared:-shared}				\
+   %{symbolic:-Bsymbolic}			\

Quoted 8 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+   %{!static:					\
+     %{rdynamic:-export-dynamic}		\
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+
+#endif /* GCC_OR1K_LINUX_H */

note that because of the -static-pie mess each
target needs a more complicated LINK_SPEC now.

Hello,

Does something like this look better?

gcc/config/or1k/linux.h +0 -0

@@ -37,8 +37,9 @@
    %{static:-Bstatic}                          \

gcc/config/or1k/linux.h line 45

Quoted 10 lines

gcc/config/or1k/linux.h +3 -2

    %{shared:-shared}                           \
    %{symbolic:-Bsymbolic}                      \
-   %{!static:                                  \
+   %{!static:%{!static-pie:                    \
      %{rdynamic:-export-dynamic}               \
-     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
+   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
 
 #endif /* GCC_OR1K_LINUX_H */

looks ok.

Quoted 8 lines

I have tested this out with or1k-linux-musl, but I get some LD complaints i.e.

.../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_end .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_start

Those are some warnings we recently added to LD, perhaps I need to rebuild the libc.a with PIE as well. I will try it out, but if anyone has some suggestions that would be helpful.

yes, musl does not build libc.a with pic by default, either use a gcc configured with --enable-default-pie or CC='gcc -fPIC' when building musl.

after that -static-pie linking should work.

(maybe musl should have an --enable-static-pie config option to make this simpler)

Quoted 48 lines · Szabolcs Nagy

Quoted 2 lines · Stafford Horne

Quoted 1 line · Szabolcs Nagy

On 27/10/18 05:37, Stafford Horne wrote:

...

Quoted 22 lines

Quoted 5 lines

Quoted 5 lines

(quoted diff) +5 -0

+#undef LINK_SPEC
+#define LINK_SPEC "%{h*}			\
+   %{static:-Bstatic}				\
+   %{shared:-shared}				\
+   %{symbolic:-Bsymbolic}			\

Quoted 8 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+   %{!static:					\
+     %{rdynamic:-export-dynamic}		\
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+
+#endif /* GCC_OR1K_LINUX_H */

note that because of the -static-pie mess each
target needs a more complicated LINK_SPEC now.

Hello,

Does something like this look better?

gcc/config/or1k/linux.h +0 -0

@@ -37,8 +37,9 @@
    %{static:-Bstatic}                          \

gcc/config/or1k/linux.h line 45

Quoted 10 lines

gcc/config/or1k/linux.h +3 -2

    %{shared:-shared}                           \
    %{symbolic:-Bsymbolic}                      \
-   %{!static:                                  \
+   %{!static:%{!static-pie:                    \
      %{rdynamic:-export-dynamic}               \
-     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
+   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
 
 #endif /* GCC_OR1K_LINUX_H */

looks ok.

Quoted 8 lines

I have tested this out with or1k-linux-musl, but I get some LD complaints i.e.

.../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_end .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_start

Those are some warnings we recently added to LD, perhaps I need to rebuild the libc.a with PIE as well. I will try it out, but if anyone has some suggestions that would be helpful.

Quoted 8 lines

yes, musl does not build libc.a with pic by default, either use a gcc configured with --enable-default-pie or CC='gcc -fPIC' when building musl.

after that -static-pie linking should work.

(maybe musl should have an --enable-static-pie config option to make this simpler)

For practical purposes, if you want to use static pie, you need a default-pie toolchain. This is because _every_ static lib you might link needs to be built with -fPIE (or -fPIC), and ensuring that happens on a package-by-package basis is largely impractical; at least it's on the same order of magnitude of difficulty as other systems integration/packaging tasks.

However from the musl side it might make sense to produce a libc_pic.a as part of the build process. This would make it easy to replace libc.a with libc_pic.a if desired, and could also be used as the basis for linking libc.so and to allow production of a stripped-down libc.so that only includes symbols a fixed set of binaries depend on. We could discuss something like this on the musl list.

Quoted 2 lines · Stafford Horne

Quoted 1 line · Szabolcs Nagy

On 27/10/18 05:37, Stafford Horne wrote:

...

Quoted 22 lines

Quoted 5 lines

Quoted 5 lines

(quoted diff) +5 -0

+#undef LINK_SPEC
+#define LINK_SPEC "%{h*}			\
+   %{static:-Bstatic}				\
+   %{shared:-shared}				\
+   %{symbolic:-Bsymbolic}			\

Quoted 8 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+   %{!static:					\
+     %{rdynamic:-export-dynamic}		\
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+
+#endif /* GCC_OR1K_LINUX_H */

note that because of the -static-pie mess each
target needs a more complicated LINK_SPEC now.

Hello,

Does something like this look better?

gcc/config/or1k/linux.h +0 -0

@@ -37,8 +37,9 @@
    %{static:-Bstatic}                          \

gcc/config/or1k/linux.h line 45

Quoted 10 lines

gcc/config/or1k/linux.h +3 -2

    %{shared:-shared}                           \
    %{symbolic:-Bsymbolic}                      \
-   %{!static:                                  \
+   %{!static:%{!static-pie:                    \
      %{rdynamic:-export-dynamic}               \
-     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}"
+     %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
+   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
 
 #endif /* GCC_OR1K_LINUX_H */

looks ok.

Quoted 8 lines

I have tested this out with or1k-linux-musl, but I get some LD complaints i.e.

.../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_end .../or1k-linux-musl/bin/ld: .../or1k-linux-musl/lib/libc.a(exit.o): non-pic relocation against symbol __fini_array_start

Those are some warnings we recently added to LD, perhaps I need to rebuild the libc.a with PIE as well. I will try it out, but if anyone has some suggestions that would be helpful.

yes, musl does not build libc.a with pic by default, either use a gcc configured with --enable-default-pie or CC='gcc -fPIC' when building musl.

after that -static-pie linking should work.

(maybe musl should have an --enable-static-pie config option to make this simpler)

I have had some inqueries into helping
bootstrap some linux nommu machines.

Quoted 2 lines · Stafford Horne

I have had some inqueries into helping
bootstrap some linux nommu machines.

For nommu, we'd need to implement an FDPIC ABI.

Otherwise, code segments cannot be mapped separately from data segments. I believe that the arm (32bit) port has recently added support for this, so you may be able to find patches from which to crib.

r~

Changes Since v2:
- Add RTEMS patches from Joel Sherrill
- Disable t-softfp-excl as suggsted by Joseph Myers
- Add new architecture flags needed to run on real FPGA's found in testing
* -mror - enable l.ror (rotate right)
* -mshftimm - enable shift/rorate by immediate instructions
- Binutils requirements are now in upstream git