Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel
On 2023-10-27 14:29 +0100, Steve McIntyre wrote: > > Are either of those ports (armeb/arm64ilp32) actually useful / alive > at this point? No, but if someone did try to build a package for those it would be incorrect for dpkg to enable these flags. The chances of anyone actually doing that are pretty low, but correct code is a good thing. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel
On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote: > Are either of those ports (armeb/arm64ilp32) actually useful / alive > at this point? Not that I have seen. I didn't think anything other than the IXP ever really used big endian and that's a long time ago. arm64ilp32 seems to serve less purpose than x32 did (and x32 doesn't seem to be doing much either). Certainly looks essentially dead at this point. -- Len Sorensen
Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel
On Fri, Oct 27, 2023 at 03:23:10PM +0200, Emanuele Rocca wrote: >Hi Guillem, > >On 2023-10-27 04:33, Guillem Jover wrote: >> Checking now again, I realize Wookey mentioned enabling this for the 3 >> arm arches (those would be arm64, armhf and armel), so the patch I >> provided would match that. But I was wondering now what about armeb and >> arm64ilp32? I mean, I assume those should be excluded for now as they >> did not get any testing, and they might not even be used/lively(?), > >Correct, there has been no testing done on armeb/arm64ilp32 as far as >I'm aware. I'd suggest enabling the feature only on armhf/armel for the >time being. Are either of those ports (armeb/arm64ilp32) actually useful / alive at this point? -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel
Hi Guillem, On 2023-10-27 04:33, Guillem Jover wrote: > Checking now again, I realize Wookey mentioned enabling this for the 3 > arm arches (those would be arm64, armhf and armel), so the patch I > provided would match that. But I was wondering now what about armeb and > arm64ilp32? I mean, I assume those should be excluded for now as they > did not get any testing, and they might not even be used/lively(?), Correct, there has been no testing done on armeb/arm64ilp32 as far as I'm aware. I'd suggest enabling the feature only on armhf/armel for the time being. Thank you for looking into this so quickly! Emanuele
Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel
Hi!
On Thu, 2023-10-26 at 12:55:32 +0200, Guillem Jover wrote:
> On Thu, 2023-10-26 at 11:40:53 +0200, Emanuele Rocca wrote:
> > Package: dpkg-dev
> > Version: 1.22.0
> > Severity: normal
> > -fstack-clash-protection is supposed to be enabled by default on amd64,
> > arm64, armhf, and armel since dpkg 1.22.0:
> > https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf
> >
> > However, due to an issue in the following conditional in
> > scripts/Dpkg/Vendor/Debian.pm, the flag is only on for amd64 and arm64:
> >
> > if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
> >
> > The value of $cpu is "arm" for both armhf and armel. Please change the
> > line above to:
> >
> > if (none { $cpu eq $_ } qw(amd64 arm64 arm)) {
>
> Ah, nice catch, and sorry! I think this happened due to copy pasting
> and modifying one of the surrounding lines. The intention was to use
> $arch here, to avoid enabling this on all arm-based arches which might
> not support this. I've queued the attached patch for my next push.
Checking now again, I realize Wookey mentioned enabling this for the 3
arm arches (those would be arm64, armhf and armel), so the patch I
provided would match that. But I was wondering now what about armeb and
arm64ilp32? I mean, I assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),
but wanted to ask in any case before pushing. If I don't hear anything
before the release, I'll just push what I proposed, and we can always
enabled these later on if needed.
Thanks,
Guillem
