Re: [PATCH] silo: Add 64-bit support
Hi, On Thu, Nov 24, 2016 at 11:26:20PM +0100, John Paul Adrian Glaubitz wrote: > On 11/24/2016 11:05 PM, Aaro Koskinen wrote: > > The same issue as with silo. > > Don't you think your statements are a bit misleading then? I didn't break > anything, > I changed the default target to 64-bit which is somewhat reasonable in the > year > 2016, isn't it. You could write the Makefile so that build works even with 32-bit userspace. I don't think it's unreasonable or rude to demand. > Or are you going to tell me now that your 333 MHz, 128 MiB RAM Sun > Ultra 5 is your everyday production machine? Yes, I'm using Ultra 5 on daily basis. The CPU is 360 MHz and with 512 MiB RAM. A.
[PATCH] silo: Add 64-bit support
This patch adds the necessary changes to compile silo
on sparc64. It adds the required stack bias for stack
operations and makes sure that all variables are properly
aligned and have the proper size, both on 32- and 64-bit
targets. These changes have been verified to work and
have been used in Debian to ship silo as a 64-bit package.
Signed-off-by: John Paul Adrian Glaubitz
---
Rules.make | 5 ++---
common/console.c| 6 +++---
common/divdi3.S | 11 ++-
common/jmp.S| 10 --
common/prom.c | 4 ++--
common/tree.c | 8
common/udivdi3.S| 10 +-
first-isofs/crt0.S | 8 +++-
first-isofs/isofs.c | 6 +++---
second/crt0.S | 21 +++--
second/disk.c | 8
second/file.c | 2 +-
second/muldi3.S | 10 +-
silo/silo.c | 12 ++--
14 files changed, 87 insertions(+), 34 deletions(-)
diff --git a/Rules.make b/Rules.make
index 0f176db..e46af48 100644
--- a/Rules.make
+++ b/Rules.make
@@ -2,10 +2,9 @@ VERSION=1.4.14
IMGVERSION=0.99
SHELL=/bin/bash
RM=rm -f
-# We want to force 32-bit builds
-CC=gcc -m32
+CC=gcc
HOSTCC=gcc
-LD=ld -m elf32_sparc
+LD=ld
AS=as
STRIP=strip
NM=nm
diff --git a/common/console.c b/common/console.c
index 44d7efb..270caca 100644
--- a/common/console.c
+++ b/common/console.c
@@ -27,7 +27,7 @@ prom_nbgetchar(void)
i = inc;
break;
case PROM_P1275:
- if (p1275_cmd ("read", 3, prom_stdin, &inc, 1) == 1)
+ if (p1275_cmd ("read", 3, (unsigned int) prom_stdin, &inc, 1)
== 1)
i = inc;
break;
}
@@ -55,7 +55,7 @@ prom_nbputchar(char c)
break;
case PROM_P1275:
outc = c;
- if (p1275_cmd ("write", 3, prom_stdout, &outc, 1) == 1)
+ if (p1275_cmd ("write", 3, (unsigned int) prom_stdout, &outc,
1) == 1)
i = 0;
break;
}
@@ -93,7 +93,7 @@ prom_puts (char *s, int len)
(*(romvec->pv_v2devops).v2_dev_write)(prom_stdout, s, len);
break;
case PROM_P1275:
- p1275_cmd ("write", 3, prom_stdout, s, len);
+ p1275_cmd ("write", 3, (unsigned int) prom_stdout, s, len);
break;
}
}
diff --git a/common/divdi3.S b/common/divdi3.S
index 681b368..128df53 100644
--- a/common/divdi3.S
+++ b/common/divdi3.S
@@ -17,9 +17,18 @@ along with GNU CC; see the file COPYING. If not, write to
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+#define STACK_BIAS 2047
+#endif
+
.data
.align 8
.globl __clz_tab
+ .register %g2,#scratch
+ .register %g3,#scratch
+
__clz_tab:
.byte 0,1,2,2,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
.byte 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
@@ -36,7 +45,7 @@ __clz_tab:
.align 4
.globl __divdi3
__divdi3:
- save %sp,-104,%sp
+ save %sp,-STACK_BIAS-104,%sp
cmp %i0,0
bge .LL40
mov 0,%l4
diff --git a/common/jmp.S b/common/jmp.S
index 3bc8c94..a446d78 100644
--- a/common/jmp.S
+++ b/common/jmp.S
@@ -18,7 +18,13 @@
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA. */
-#define _SV save %sp, -0x40, %sp
+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+# define STACK_BIAS 2047
+#endif
+
+#define _SV save %sp, -STACK_BIAS-0x40, %sp
#define _RV restore
#define FLUSH_ALL_WINDOWS \
_SV; _SV; _SV; _SV; _SV; _SV; _SV; \
@@ -46,7 +52,7 @@ __longjmp:
FLUSH_ALL_WINDOWS
ld [%o0], %o7 /* Return PC. */
ld [%o0 + 4], %fp /* Saved SP. */
- sub %fp, 64, %sp/* Allocate a register save area. */
+ sub %fp, 64+STACK_BIAS, %sp /* Allocate a register save area. */
tst %o1
be,a 1f
mov 1, %o1
diff --git a/common/prom.c b/common/prom.c
index 939bbb9..7585e10 100644
--- a/common/prom.c
+++ b/common/prom.c
@@ -196,7 +196,7 @@ int prom_map(int mode, unsigned long long size,
P1275_ARG_64B(3) | P1275_ARG_64B(4) |
P1275_ARG_64B(6) | 7,
"map",
- prom_get_mmu_ihandle(),
+ (unsigned int) prom_get_mmu_ihandle(),
mode,
size,
vaddr,
@@ -211,7 +211,7 @@ void prom_unmap(unsigned long long size, unsigned long long
vaddr)
p1275_cmd("call-method",
P1275_ARG_64B(2) | P1275_ARG_64B(3) | 4,
"unmap",
- prom_get_mmu_ihandle(),
+ (unsigned int) prom_get_mmu_ihandle(),
size,
vaddr);
silo: Add 64-bit support, v2
Replaced "LD=ld -m elf64_sparc" with "LD=ld" which essentially reverts c836dbda which hard-wired the build to 32 bits. Since both 32- and 64-bit builds are supported these days, this should no longer be necessary. Adrian
Re: [PATCH] silo: Add 64-bit support
On 11/24/2016 11:51 PM, Aaro Koskinen wrote: > You could write the Makefile so that build works even with 32-bit > userspace. I don't think it's unreasonable or rude to demand. It isn't. But it's always possible to say that in polite way. I'm trying to help improving things, not forcing anything to anyone. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] silo: Add 64-bit support
On 11/24/2016 11:32 PM, James Clarke wrote: > Part of the problem is not forcing 64-bit, but that the Makefile is > inconsistent. > The default CC is gcc without any flags, but ld is given -m elf64_sparc. If > you > are running with sparc32 as your default target, gcc will generate 32-bit > files > but ld expects 64-bit. If you really want to force 64-bit, you should also > pass > appropriate -m64/-64 flags to gcc/as. However, I think the sensible, least > controversial solution is to just drop the -m elf64_sparc and let everything > be the default. It was only changed to force 32-bit in c836dbda because 64-bit > support wasn’t present. Thank you! This is actually very constructive criticism which actually helps improving the patch. I'll look into improving the Makefile. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] silo: Add 64-bit support
> On 24 Nov 2016, at 22:26, John Paul Adrian Glaubitz > wrote: > > On 11/24/2016 11:05 PM, Aaro Koskinen wrote: >> I think that's your job to try. If you want to "add 64-bit support" >> (instead of forcing it to everybody), do the required changes so that >> it's still works for everybody without extra fiddling. > > Don't be so rude, I'm not forcing anything onto anyone. > Also you broke the tilo build... >>> >>> Not here. Just tried it again and it builds fine. Can you be more specific? >> >> The same issue as with silo. > > Don't you think your statements are a bit misleading then? I didn't break > anything, > I changed the default target to 64-bit which is somewhat reasonable in the > year > 2016, isn't it. > > Or are you going to tell me now that your 333 MHz, 128 MiB RAM Sun Ultra 5 is > your everyday production machine? Part of the problem is not forcing 64-bit, but that the Makefile is inconsistent. The default CC is gcc without any flags, but ld is given -m elf64_sparc. If you are running with sparc32 as your default target, gcc will generate 32-bit files but ld expects 64-bit. If you really want to force 64-bit, you should also pass appropriate -m64/-64 flags to gcc/as. However, I think the sensible, least controversial solution is to just drop the -m elf64_sparc and let everything be the default. It was only changed to force 32-bit in c836dbda because 64-bit support wasn’t present. Regards, James
Re: [PATCH] silo: Add 64-bit support
On 11/24/2016 11:05 PM, Aaro Koskinen wrote: > I think that's your job to try. If you want to "add 64-bit support" > (instead of forcing it to everybody), do the required changes so that > it's still works for everybody without extra fiddling. Don't be so rude, I'm not forcing anything onto anyone. >>> Also you broke the tilo build... >> >> Not here. Just tried it again and it builds fine. Can you be more specific? > > The same issue as with silo. Don't you think your statements are a bit misleading then? I didn't break anything, I changed the default target to 64-bit which is somewhat reasonable in the year 2016, isn't it. Or are you going to tell me now that your 333 MHz, 128 MiB RAM Sun Ultra 5 is your everyday production machine? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: SILO Issues on an E4900
On 24/11/16 21:26, vinc...@cojot.name wrote: > A while back I stumbled onto an old post talking about the 'Illegal > instruction' issue with SILO on serengeti machines: > > http://helenos-blog.pavel-rimsky.cz/?p=3 > > Any thoughts? > > Note that I have not personally verified that it works or not (I sold my > US-IIICu sb2k some time ago already...) > > My 2c, > > Vincent FWIW we have a similar hack in OpenBIOS for a.out binaries which rears its head when trying to boot NextSTEP in QEMU: https://github.com/openbios/openbios/blob/master/libopenbios/aout_load.c. For a.out binaries we relocate the binary back down over its header after load so we can execute directly at 0x4000 (load-base). This was modelled after observing similar code in the official Sun OpenBOOT implementation of init-program which can be found here: https://github.com/openbios/openboot/blob/master/obp/arch/sun4u/go.fth. Probably the first thing to check is that the a.out magic is being generated correctly in SILO to match the above code in order to trigger the relocation, which in itself is likely a hold-over from the very early days of OpenBOOT. ATB, Mark.
Re: [PATCH] silo: Add 64-bit support
Hi, On Thu, Nov 24, 2016 at 10:51:14PM +0100, John Paul Adrian Glaubitz wrote: > On 11/24/2016 10:23 PM, Aaro Koskinen wrote: > > This breaks the native build on my Sun Ultra 5 with 32-bit userspace and GCC > > defaulting to ultrasparc: > > Well, you can just change this part back to "elf32_sparc" and it will work. > Might > even be possible to omit the "-m" option altogether to it will default to -m > native. I think that's your job to try. If you want to "add 64-bit support" (instead of forcing it to everybody), do the required changes so that it's still works for everybody without extra fiddling. > > Also you broke the tilo build... > > Not here. Just tried it again and it builds fine. Can you be more specific? The same issue as with silo. A.
Re: [PATCH] silo: Add 64-bit support
On 11/24/2016 10:23 PM, Aaro Koskinen wrote: > This breaks the native build on my Sun Ultra 5 with 32-bit userspace and GCC > defaulting to ultrasparc: Well, you can just change this part back to "elf32_sparc" and it will work. Might even be possible to omit the "-m" option altogether to it will default to -m native. > Also you broke the tilo build... Not here. Just tried it again and it builds fine. Can you be more specific? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] silo: Add 64-bit support
Hi, On Thu, Nov 24, 2016 at 06:33:30PM +0100, John Paul Adrian Glaubitz wrote: > -# We want to force 32-bit builds > -CC=gcc -m32 > +# We want to force 64-bit builds > +CC=gcc > HOSTCC=gcc > -LD=ld -m elf32_sparc > +LD=ld -m elf64_sparc This breaks the native build on my Sun Ultra 5 with 32-bit userspace and GCC defaulting to ultrasparc: $ make [...] make[1]: Entering directory '/home/aaro/silo/first' gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing -DSMALL_RELOC=0x28 -DLARGE_RELOC=0x38 -fno-stack-protector -c first.S -o first.o ld -m elf64_sparc -N -Ttext 0x4000 -o first first.o ld: sparc architecture of input file `first.o' is incompatible with sparc:v9 output Makefile:39: recipe for target 'first' failed make[1]: *** [first] Error 1 make[1]: Leaving directory '/home/aaro/silo/first' Makefile:15: recipe for target 'all' failed make: *** [all] Error 1 Also you broke the tilo build... A.
Re: SILO Issues on an E4900
A while back I stumbled onto an old post talking about the 'Illegal instruction' issue with SILO on serengeti machines: http://helenos-blog.pavel-rimsky.cz/?p=3 Any thoughts? Note that I have not personally verified that it works or not (I sold my US-IIICu sb2k some time ago already...) My 2c, Vincent On Thu, 24 Nov 2016, John Paul Adrian Glaubitz wrote: On 11/24/2016 05:10 PM, David Miller wrote: From: John Paul Adrian Glaubitz Date: Thu, 24 Nov 2016 11:00:29 +0100 For SILO, Oracle has created several patches which port SILO to 64-bit (I extracted that patch and applied it to the Debian package) and other packages which improve SILO on modern sun4v machines. All of the changes which were submitted to this list I reviewed and either they were poorly formed or did not apply cleanly at all. That doesn't sound too good :(. Everything fell to /dev/null and the developers made no effort whatsoever to address the feedback and make the patches actually apply to the SILO git tree properly. The patches were not only poorly formed, or not able to apply to the GIT tree, they were also extremely poorly documented with either a very terse and vague commit message provided or none at all. When I would ask why a change was doing X or Y, I received no response at all. Hmm. I have this small patch which enables 64-bit support. It's rather clean and I'll try to submit it later today to get at least some improvements. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] silo: Add 64-bit support
On 2016-11-24 12:33, John Paul Adrian Glaubitz wrote: Hi Dave! As promised in another mail earlier today, here is the current patch changes that we are currently using on top of silo HEAD to build it as a 64-bit package in Debian unstable (sparc64). The silo package has been shipped in Debian with 64-bit support for a while now without any major issues for most people. So far, I only know of two cases where people had issues but this seems to affect Serengeti and Amazon machines only and not a result of this particular patch. Thanks, Adrian [1] http://marc.info/?l=linux-sparc&m=147363964605901&w=2 Just as a side note, i can personally verify that both Debian SILO and current SILO are broken on Serengeti / Amazon in the same way. 64 Bit patches make no absolutely difference here.
Re: [PATCH] silo: Add 64-bit support
On Nov 24, 2016, at 6:43 PM, alexmcwhir...@triadic.us wrote: > >> On 2016-11-24 12:33, John Paul Adrian Glaubitz wrote: >> Hi Dave! >> As promised in another mail earlier today, here is the current patch >> changes that we are currently using on top of silo HEAD to build >> it as a 64-bit package in Debian unstable (sparc64). >> The silo package has been shipped in Debian with 64-bit support for >> a while now without any major issues for most people. So far, I >> only know of two cases where people had issues but this seems to >> affect Serengeti and Amazon machines only and not a result of this >> particular patch. >> Thanks, >> Adrian >>> [1] http://marc.info/?l=linux-sparc&m=147363964605901&w=2 > > Just as a side note, i can personally verify that both Debian SILO and > current SILO are broken on Serengeti / Amazon in the same way. 64 Bit patches > make no absolutely difference here. Thank you very much for confirming this! I was actually hoping for this exact statement! Thanks, Adrian
Re: Bug#845461: gcc-6: Please build with --with-cpu=ultrasparc on sparc
I'm pretty confident that --with-cpu=ultrasparc won't do any harm in 64-bit mode, but Jose (CC'ed as gcc upstream) will hopefully correct me here if I'm wrong. The cpu selected in --with-cpu impacts both -m64 and -m32 in a biarch compiler. However, I can't say anything about the patch since I lack the most basic context here, i.e. I have no idea what the contents of that rules2 file are.
[PATCH] silo: Add 64-bit support
This patch adds the necessary changes to compile silo
on sparc64. It adds the required stack bias for stack
operations and makes sure that all variables are properly
aligned and have the proper size, both on 32- and 64-bit
targets. These changes have been verified to work and
have been used in Debian to ship silo as a 64-bit package.
Signed-off-by: John Paul Adrian Glaubitz
---
Rules.make | 6 +++---
common/console.c| 6 +++---
common/divdi3.S | 11 ++-
common/jmp.S| 10 --
common/prom.c | 4 ++--
common/tree.c | 8
common/udivdi3.S| 10 +-
first-isofs/crt0.S | 8 +++-
first-isofs/isofs.c | 6 +++---
second/crt0.S | 21 +++--
second/disk.c | 8
second/file.c | 2 +-
second/muldi3.S | 10 +-
silo/silo.c | 12 ++--
14 files changed, 88 insertions(+), 34 deletions(-)
diff --git a/Rules.make b/Rules.make
index 0f176db..4b023a7 100644
--- a/Rules.make
+++ b/Rules.make
@@ -2,10 +2,10 @@ VERSION=1.4.14
IMGVERSION=0.99
SHELL=/bin/bash
RM=rm -f
-# We want to force 32-bit builds
-CC=gcc -m32
+# We want to force 64-bit builds
+CC=gcc
HOSTCC=gcc
-LD=ld -m elf32_sparc
+LD=ld -m elf64_sparc
AS=as
STRIP=strip
NM=nm
diff --git a/common/console.c b/common/console.c
index 44d7efb..270caca 100644
--- a/common/console.c
+++ b/common/console.c
@@ -27,7 +27,7 @@ prom_nbgetchar(void)
i = inc;
break;
case PROM_P1275:
- if (p1275_cmd ("read", 3, prom_stdin, &inc, 1) == 1)
+ if (p1275_cmd ("read", 3, (unsigned int) prom_stdin, &inc, 1)
== 1)
i = inc;
break;
}
@@ -55,7 +55,7 @@ prom_nbputchar(char c)
break;
case PROM_P1275:
outc = c;
- if (p1275_cmd ("write", 3, prom_stdout, &outc, 1) == 1)
+ if (p1275_cmd ("write", 3, (unsigned int) prom_stdout, &outc,
1) == 1)
i = 0;
break;
}
@@ -93,7 +93,7 @@ prom_puts (char *s, int len)
(*(romvec->pv_v2devops).v2_dev_write)(prom_stdout, s, len);
break;
case PROM_P1275:
- p1275_cmd ("write", 3, prom_stdout, s, len);
+ p1275_cmd ("write", 3, (unsigned int) prom_stdout, s, len);
break;
}
}
diff --git a/common/divdi3.S b/common/divdi3.S
index 681b368..128df53 100644
--- a/common/divdi3.S
+++ b/common/divdi3.S
@@ -17,9 +17,18 @@ along with GNU CC; see the file COPYING. If not, write to
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+#define STACK_BIAS 2047
+#endif
+
.data
.align 8
.globl __clz_tab
+ .register %g2,#scratch
+ .register %g3,#scratch
+
__clz_tab:
.byte 0,1,2,2,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
.byte 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
@@ -36,7 +45,7 @@ __clz_tab:
.align 4
.globl __divdi3
__divdi3:
- save %sp,-104,%sp
+ save %sp,-STACK_BIAS-104,%sp
cmp %i0,0
bge .LL40
mov 0,%l4
diff --git a/common/jmp.S b/common/jmp.S
index 3bc8c94..a446d78 100644
--- a/common/jmp.S
+++ b/common/jmp.S
@@ -18,7 +18,13 @@
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA. */
-#define _SV save %sp, -0x40, %sp
+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+# define STACK_BIAS 2047
+#endif
+
+#define _SV save %sp, -STACK_BIAS-0x40, %sp
#define _RV restore
#define FLUSH_ALL_WINDOWS \
_SV; _SV; _SV; _SV; _SV; _SV; _SV; \
@@ -46,7 +52,7 @@ __longjmp:
FLUSH_ALL_WINDOWS
ld [%o0], %o7 /* Return PC. */
ld [%o0 + 4], %fp /* Saved SP. */
- sub %fp, 64, %sp/* Allocate a register save area. */
+ sub %fp, 64+STACK_BIAS, %sp /* Allocate a register save area. */
tst %o1
be,a 1f
mov 1, %o1
diff --git a/common/prom.c b/common/prom.c
index 939bbb9..7585e10 100644
--- a/common/prom.c
+++ b/common/prom.c
@@ -196,7 +196,7 @@ int prom_map(int mode, unsigned long long size,
P1275_ARG_64B(3) | P1275_ARG_64B(4) |
P1275_ARG_64B(6) | 7,
"map",
- prom_get_mmu_ihandle(),
+ (unsigned int) prom_get_mmu_ihandle(),
mode,
size,
vaddr,
@@ -211,7 +211,7 @@ void prom_unmap(unsigned long long size, unsigned long long
vaddr)
p1275_cmd("call-method",
P1275_ARG_64B(2) | P1275_ARG_64B(3) | 4,
"unmap",
- prom_get_mmu_ihandle(),
+ (unsigned int) prom_get_mmu_ihandle(),
[PATCH] silo: Add 64-bit support
Hi Dave! As promised in another mail earlier today, here is the current patch changes that we are currently using on top of silo HEAD to build it as a 64-bit package in Debian unstable (sparc64). The silo package has been shipped in Debian with 64-bit support for a while now without any major issues for most people. So far, I only know of two cases where people had issues but this seems to affect Serengeti and Amazon machines only and not a result of this particular patch. Thanks, Adrian > [1] http://marc.info/?l=linux-sparc&m=147363964605901&w=2
Re: SILO Issues on an E4900
From: John Paul Adrian Glaubitz Date: Thu, 24 Nov 2016 11:00:29 +0100 > For SILO, Oracle has created several patches which port SILO to 64-bit (I > extracted > that patch and applied it to the Debian package) and other packages which > improve > SILO on modern sun4v machines. All of the changes which were submitted to this list I reviewed and either they were poorly formed or did not apply cleanly at all. Everything fell to /dev/null and the developers made no effort whatsoever to address the feedback and make the patches actually apply to the SILO git tree properly. The patches were not only poorly formed, or not able to apply to the GIT tree, they were also extremely poorly documented with either a very terse and vague commit message provided or none at all. When I would ask why a change was doing X or Y, I received no response at all.
Re: SILO Issues on an E4900
On 11/24/2016 05:10 PM, David Miller wrote: > From: John Paul Adrian Glaubitz > Date: Thu, 24 Nov 2016 11:00:29 +0100 > >> For SILO, Oracle has created several patches which port SILO to 64-bit (I >> extracted >> that patch and applied it to the Debian package) and other packages which >> improve >> SILO on modern sun4v machines. > > All of the changes which were submitted to this list I reviewed and > either they were poorly formed or did not apply cleanly at all. That doesn't sound too good :(. > Everything fell to /dev/null and the developers made no effort > whatsoever to address the feedback and make the patches actually apply > to the SILO git tree properly. > > The patches were not only poorly formed, or not able to apply to the > GIT tree, they were also extremely poorly documented with either a > very terse and vague commit message provided or none at all. When > I would ask why a change was doing X or Y, I received no response > at all. Hmm. I have this small patch which enables 64-bit support. It's rather clean and I'll try to submit it later today to get at least some improvements. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
Guillem Jover dixit: >> Yes, but they *do* break anything that >> - acts on the CFLAGS (and LDFLAGS) variables >> - uses klcc or other compiler wrappers that don't understand -specs >> - uses clang or pcc or whatever other compilers > >The default dpkg build flags have always been tied to the specific >language compiler version currently marked as the default (for C that >would currently be gcc-6). Sure, but we do have other compilers and compiler wrappers in the archive, and packages are using them. >As long as gcc enables PIE on a subset, there will be need to inject >some form of specs on either subset of those arches, either on >hardening=+pie or on hardening=-pie, pick yout poison. :( […] >> Either are *much* better than the current way. > >Well you and me both, I'm just adapting the dpkg-buildflags to the >current gcc situation. :/ This sounds to me like we should reassign this to GCC (and remove all the… well, “offending”, no offence intended, code from dpkg). >Having a subset of architectures is a pain for maintainers as they True, so GCC should just enable it on all architectures where it at all works. >Well I think we should be enabling all hardening flags directly in >gcc, but now that we have the specs files I guess it would not be >too bad to enable them just in dpkg, but I agree either would be >preferable. :/ OK, thank you. bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
Hi! On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote: > clone 845193 -1 > reassign -1 dpkg > retitle -1 dpkg: please do not add -specs= flags only on some architectures > thanks I'm afraid I'll have to wontfix this because it is not really implementable. See below… :/ > Guillem Jover dixit: > >Those specs files should make it possible to build stuff with PIE > > Yes, but they *do* break anything that > - acts on the CFLAGS (and LDFLAGS) variables > - uses klcc or other compiler wrappers that don't understand -specs > - uses clang or pcc or whatever other compilers The default dpkg build flags have always been tied to the specific language compiler version currently marked as the default (for C that would currently be gcc-6). > Worse, they break *differently* on whether… > > >Precisely to make the behavior consistent on all architectures, dpkg > >enables PIE (conditionally if no other flags marks it as to be > >disabled) on all architectures were gcc has not enabled this by > >default. > > … that. And that is just plain wrong. Either dpkg should inject > -specs= stuff on all architectures or on none. Differing like this > just invites hidden and hard to track down bugs. As long as gcc enables PIE on a subset, there will be need to inject some form of specs on either subset of those arches, either on hardening=+pie or on hardening=-pie, pick yout poison. :( Injecting just the raw -fno-PIE and -no-pie does not work, so when you need to disable those we need to pass via specs files. > Please get an agreement with the GCC maintainer on how to proceed > from here. > > Personally, I’d still prefer for GCC to behave as on other systems, > i.e. not to enable PIE by default, and to have it done completely > within dpkg, but I can *also* live with it being done exclusively > in GCC. > > Either are *much* better than the current way. Well you and me both, I'm just adapting the dpkg-buildflags to the current gcc situation. :/ > >Also BTW the gcc maintainer asked that porters > >interested could request PIE to be enabled by default in gcc. > > What difference does it make on whether GCC or dpkg enables PIE? It means it should at least get the same behavior from gcc as all official ports, it is more transparent and should not suffer from unbalanced passing of CFLAGS w/o LDFLAGS or the other way around, for example. Of course that does not mean that package might still not fail, in case they try to link PIE code into a shared library or similar. > The two last quote sections make it clear that any architecture > that currently has PIE enabled in dpkg should have it enabled in > GCC in the first place. Enabling new build flags in dpkg has always been done globally, except for specific blacklists on things that were completely broken in the toolchain, which have then been enabled eventually when they got fixed. Having a subset of architectures is a pain for maintainers as they get different resulting objects depending on the architectures, it also changes the semantics from before the gcc default change, as previously explicitly enabling PIE was global, and now would be for a subset. Or worse, the new semantics would need to be that by default you get PIE on a subset but if you pass hardening=+pie on each package you get it enabled globally? Pretty unintuitive IMO. > (Did dpkg enable that on porters’ requests? > It does not look like that to me. This smells like overstepping > boundaries.) If porters are unhappy about this, I'll revert PIE for those ports in dpkg, but this will not make the situation less of a mess, hardening=-pie will still need the specs files on ports were gcc enables it by default, and hardening=+pie might need them on the ones that do not… > tl;dr: I don’t care as much _which_ of GCC xor dpkg does it, > as long as only one does it. FFS, just enable it on all of them > unless known to absolutely not work; that’d still be better than > the current mess. Well I think we should be enabling all hardening flags directly in gcc, but now that we have the specs files I guess it would not be too bad to enable them just in dpkg, but I agree either would be preferable. :/ Thanks, Guillem
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
clone 845193 -1 reassign -1 dpkg retitle -1 dpkg: please do not add -specs= flags only on some architectures thanks Guillem Jover dixit: >> I cannot build openssl1.0 any longer. Downgrading all binary >> packages from src:dpkg to 1.18.10 makes the build succeed. Interestingly enough, src:openssl (1.1) works, so… >So, I think I'll reassign this to openssl1.0, if no other feedback … this is probably legit. But I would *still* like to raise another point. >Those specs files should make it possible to build stuff with PIE Yes, but they *do* break anything that - acts on the CFLAGS (and LDFLAGS) variables - uses klcc or other compiler wrappers that don't understand -specs - uses clang or pcc or whatever other compilers Worse, they break *differently* on whether… >Precisely to make the behavior consistent on all architectures, dpkg >enables PIE (conditionally if no other flags marks it as to be >disabled) on all architectures were gcc has not enabled this by >default. … that. And that is just plain wrong. Either dpkg should inject -specs= stuff on all architectures or on none. Differing like this just invites hidden and hard to track down bugs. Please get an agreement with the GCC maintainer on how to proceed from here. Personally, I’d still prefer for GCC to behave as on other systems, i.e. not to enable PIE by default, and to have it done completely within dpkg, but I can *also* live with it being done exclusively in GCC. Either are *much* better than the current way. >if no other feedback is provided showing that this is a problem in >dpkg itself, such as PIE not working at all there, and a request to >disable it for x32 in dpkg as non-functional. This can be done just as well on the GCC side. >Also BTW the gcc maintainer asked that porters >interested could request PIE to be enabled by default in gcc. What difference does it make on whether GCC or dpkg enables PIE? The two last quote sections make it clear that any architecture that currently has PIE enabled in dpkg should have it enabled in GCC in the first place. (Did dpkg enable that on porters’ requests? It does not look like that to me. This smells like overstepping boundaries.) tl;dr: I don’t care as much _which_ of GCC xor dpkg does it, as long as only one does it. FFS, just enable it on all of them unless known to absolutely not work; that’d still be better than the current mess. Thanks, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: Bug#845101: chasen: FTBFS on sparc64 due to mismatched symbols file
Control: fixed -1 2.4.5-30 Hi! This has now been fixed as of version 2.4.5-32. Closing. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: SILO Issues on an E4900
Hi Louis! On 11/24/2016 10:35 AM, Louis Liu wrote: > I boot with the latest debian sparc64 install image (2006-11-22), and > have the same problem. > > It looks like _start is placed on 0x4020? > > Hope the following messages is helpful Thanks for the feedback! So, the problem is that while several patches for SILO and even GRUB exist which improve these bootloaders on sparc64, none of them have actually officially been merged yet. For SILO, Oracle has created several patches which port SILO to 64-bit (I extracted that patch and applied it to the Debian package) and other packages which improve SILO on modern sun4v machines. I tried applying these patches as well, but I didn't really understand them nor was I able to get them apply. These patches are part of the SILO SRPM package [1] in Linux for SPARC. If anyone can get the patches apply to SILO git [2], I'd be happy to apply them to the Debian package and rebuild the installation images. As for GRUB, all the patches for adding sparc64 support [3] have still not been merged into GRUB upstream [4] despite two of the GRUB upstream developers working for Oracle. I don't really understand why it takes them to long, but it's one of the things that frustrates me most with the work on the sparc64 port. There are actually several really good improvements made by very talented developers, but instead of merging those and making these changes available for every sparc64 users, these patches don't get the attention they deserve :(. Adrian > [1] > http://yum.oracle.com/repo/linux_sparc64/latest/silo-1.4.14-4.0.18.el6.src.rpm > [2] http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git > [3] https://github.com/esnowberg/grub2-sparc > [4] http://git.savannah.gnu.org/cgit/grub.git -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
