[continued from previous message]

every package that might be using autotools and not using autoreconf
at build time, or to even update triplet matches in configure scripts
and similar, which might be "acceptable" for a new arch, but seems disproportionate for a new ISA, so yes, as mentioned I agree it's not
viable.

OK. Let's stop worrying about that then :)

On Thu, 2023-09-21 at 14:43:42 +1200, Michael Hudson-Doyle wrote:

* Should the ISA influence the toolchain via toolchain defaults or dpkg-buildflags?
* How is the default ISA for a buildd chroot selected?

So the clear downsides of either modifying the default toolchain or having to provide an additional one is that this seems pretty heavy weight. Also because people might want to build optimized variants locally w/o having to mess with their already existing toolchains.
(I'm not sure whether something going along the lines of <https://git.hadrons.org/cgit/debian/fakecross.git> could be an
option, although as mentioned above, if that would imply new triplets, then probably not.)

So the easiest way might indeed be by controlling this via an envvar,

DEB_HOST_ARCH_ISA?

Yeah, that works, and follows the current DPKG_*_ARCH_ABI lead for
example.

which dpkg-buildpackage could also setup internally via a new option,
say --arch-isa=amd64v3 or similar

--host-arch-isa would be more coherent I think.

Ah absolutely! For some reason had --arch in mind as a valid option
(I only see it now in dpkg-scanpackages :D, or maybe I was thinking
about --host-isa :).

I guess one could add support for --target-host-arch-isa to build a toolchain that defaults to a particular ISA. But well.

Yes, the ISA support in dpkg should be extensive enough (so that if
this needs to be supported in the toolchain, then it is possible).

So to summarise, here are the generic changes that I think need to be

made

to src:dpkg to support variant ISAs as a thing:

* add get_host_arch_isa() to Dpkg::Arch

Yes (perhaps as mentioned below also just get_host_isa()).

* dpkg-gencontrol records DEB_HOST_ARCH_ISA into DEBIAN/control as ArchitectureIsa

Probably better Architecture-Isa, otherwise the current automatic
case folding would make it end up as Architectureisa.

Heh OK.

* dpkg-architecture emits DEB_HOST_ARCH_ISA and grows --host-arch-isa

flag

Also DEB_BUILD_ARCH_ISA and DEB_TARGET_ARCH_ISA, and also grows a --target-arch-isa (but I'm thinking whether the shorter --host-isa would
be nicer, for example the --match-bits are not spelled --match-arch-bits, which would seem also a bit redundant).

* dpkg-buildpackage passes --host-arch-isa to dpkg-architecture

Yes, but only when not the baseline.

I think what I meant here was that if you pass one of the --*-arch-isa
flags dpkg-buildpackage, it gets passed along to dpkg-architecture (as --host-arch etc are).

* dpkg-genchanges should record the ISA in the changes file somehow I

guess?

Yes, also dpkg-genbuildinfo.

Oh yeah. Although on a quick look dpkg-genbuildinfo gets the architecture
from the filename...

This could be done either from the
envvars, or perhaps through the debian/files attributes support. But
given that this is supposedly build global (I think it would be rather
weird to end up with a .changes including say _amd64.deb and
_amd64v3.deb file references from the same build),

Ah yes that's true.

then probably using
the envvar might be the better way.

* dpkg-deb records the ISA in the file name

Yes.

Have I missed anything?

Nothing else comes to mind right now (except what I might have already added).

Well of course I wrote this question in before going back and adding the
stuff about having this all be driven by dpkg --add-archiitecture isa
amd64v3 or anything like that. So those changes probably need to be hashed
out too?

(Hmm does anything need to reject unknown values
found in DEB_HOST_ARCH_ISA / --host-arch-isa? Probably...)

I guess it indeed makes sense to define what ISAs are supported, and
either error out or warn and ignore such values. So there might be a
need to add something like a new data/isatable.

I notice that --add-architecture doesn't seem to do any checking.

Conceptually slightly separately, it might make sense to add a build "feature" to Dpkg::Vendor::Debian to allow setting -march (and -mtune?)

Then when we want to add support to an ISA, we add a little thing to set_build_features (in either Vendor::Debian or Vendor::Ubuntu or

wherever)

that maps get_host_arch_isa() to values for the march-influencing

feature.

Hmm, right, how to hook this. I'm not sure the current interface is good enough to describe this via build flags features, because such new feature area would expose arch-specific features. I have been thinking through
the build flags and will try to send a proposal/RFC to revamp parts of
it during the weekend.

Did that happen? I didn't see if if so.

But I think the ISA stuff is better just handled
(at leas for now) directly by injecting whatever flags when the requested
ISA is different to the baseline.

Well that's easy enough too.

Cheers & thanks for the continued thoughts,
mwh

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 4 Nov 2023 at 02:02, Guillem Jover &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_
quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>

On Thu, 2023-11-02 at 15:27:54 +0000, Michael Hudson-Doyle wrote:<br>
&gt; On Tue, 31 Oct 2023 at 09:21, Guillem Jover wrote:<br>
&gt; &gt; This can be used among other things to set up foreign chroots, by<br> &gt; &gt; running the host tools, so disallowing installation could be<br>
&gt; &gt; problematic. Even though I guess there could be a warning about this,<br>
&gt; &gt; or maybe it could be controlled through a force option, although both<br>
&gt; &gt; seems like they could be disruptive.<br>

&gt; Of course in such cases dpkg knows that something funny is going on and<br>
&gt; could suppress the warning itself.<br>

Right, also true.<br>

&gt; I spent a few minutes trying to think hard about this and I honestly don&#39;t<br>
&gt; think I can predict whether trying to prevent installation of incompatible<br>
&gt; packages is worth it (after all one of the ways users could get into<br> &gt; trouble would be moving an installed system to a different CPU and having<br>
&gt; binaries start to fail and obviously dpkg can&#39;t help there).<br>
&gt; <br>
&gt; One result of this thinking was: I had been thinking/assuming the issue of<br>
&gt; which variants to consider would be apt configuration, but maybe dpkg<br> &gt; configuration would make more sense (after all, --add-architecture is a<br>
&gt; parameter to dpkg). And in this case, dpkg could object when installing a<br>
&gt; variant that has not been configured.<br>

Yes, the &quot;plan&quot; has been to add support for run-time CPU attributes,<br>

[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

[continued from previous message]

would configure gcc with --with-arch64=x86-64-v3 and then dpkg-architecture would parse the output of gcc -Q --help=target to set DEB_HOST_ARCH_VARIANT appropriately? (modulo mistakes in details) Or do you mean something else entirely?

Some of the above problems could perhaps be avoided if we introduced
a concept of architecture aliases/ISAs (similar to what rpm has), which
would side-step the pool sharing issue, the binary package renaming,
etc. One big issue with this is that it requires for dpkg to have an exhaustive table of all such aliases, and if there's ever a new alias
added, old dpkg versions need to be updated or they will not understand
what they match with. So this does not seem ideal either. So I guess this
is a variation over your proposal, but perhaps this could still be used
in specific contexts, say only at build-time (but not for dependency relationships), for repo management (say binary-arm64v9/Packages.xz),
or binary package names where the field would specify the actual name
for the filename, say:

Architecture: arm64
ArchitectureIsa: arm64v9

or maybe better:

Architecture: arm64
ArchitectureIsa: v9

resulting in dpkg-deb generating:

binpkg_1.0-1_arm64v9.deb

but targeting arm64.

I'm not sure but I think you have talked yourself into suggesting something very similar to my proposal here?

I also think I prefer naming this explicitly as ISA
variants, if you will, than just architecture variants as that gives
way too much room

Certainly I think all the interesting use cases are basically changing the
set of instructions emitted by the toolchains by default. I suppose you
could have a variant that changed the set of hardening flags or something
but that doesn't seem an especially good idea. So I guess I'd be happy with s/ArchitectureVariant/ArchitectureISA/ everywhere.

(which perhaps we want, but then that has other
implications over compatibility), and for the field perhaps just Isa is better, to avoid the implicit repetition of ArchitectureInstructionSetArchitecture :), but that makes it less easy
to associate both as related.

In the end though, I think there are perhaps bigger constraints from
the infra side of things than the package tooling, stuff like archive management software, or binary transition migration and similar.

I think I managed to convince myself that most things like britney and ben
can and should treat each variant/ISA as a separate architecture. It
depends a bit how publication is done in the case where not all packages
are built for all ISAs but not in very interesting ways I think. And my intention is to start with amd64v3 and build everything for this ISA (as we have heaps of builder capacity on amd64 in Ubuntu) and sidestep worrying
about that for a little while.

In terms of building consensus around this design, I thought it makes

sense

to start at the bottom of the stack and so here I am on this mailing list :-) I guess in due course this could become a DEP, and would certainly

need

to be discussed on debian-devel before getting too far.

I'm not sure there's ever been much of a wide interest in something
like this in Debian TBH. Due to deployment and increased infra
overhead at least?

Yes that's fair. And as I said somewhere, I myself am not proposing to
support any additional ISAs in Debian at this time.

What do you think? Have I missed any glaring implications?

No, I think the overall picture is about right, and captures most of the things we have discussed at various times and places in the past. :)

I am very happy to read this!

Is there a better way of doing this?

I think starting from 5, the rest are probably just details to hammer
out, but not insurmountable things.

Great. The things I see as a bit vague at a base level currently are:

* Should the ISA influence the toolchain via toolchain defaults or dpkg-buildflags?
* How is the default ISA for a buildd chroot selected?

There is also the question of whether partial coverage of an ISA is handled
by the package publisher or client side in apt but that's at least one
level higher.

Cheers,
mwh

<div dir="ltr"><div dir="ltr">On Wed, 6 Sept 2023 at 21:27, Guillem Jover &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br></blockquote><div><br></div><div>Hi!</div><div><br></div><div>Thanks for the considered response. And sorry for the very slow reply.</div><div> </div><blockquote class="gmail_
quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Fri, 2023-09-01 at 08:43:55 +1200, Michael Hudson-Doyle wrote:<br>
&gt; Recently the topic of exploiting newer instructions without dropping<br> &gt; support for older machines has come up several times inside Ubuntu<br> &gt; engineering. I understand this topic has come up several times in the past<br>
&gt; for Debian as well, but nothing has really come of it to date.<br>

I also had a chat about this with Matthias Klose (CCed) around 2022-05.<br>

&gt; I&#39;ve spent a while thinking through the options and coming up with a design<br>
&gt; and wrote some notes into a wiki page:<br>
&gt; <a href="https://wiki.debian.org/ArchitectureVariants" rel="noreferrer" target="_blank">https://wiki.debian.org/ArchitectureVariants</a><br>

I think we are already doing 1, 2 and 3. I agree 4 is just wrong. And<br> something like 5 is what I suggested to Matthias for Ubuntu when we<br>
last discussed it as the best way to go about this.<br></blockquote><div><br></div><div>OK, glad we agree to this point.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:
1ex">
I&#39;m not sure I entirely agree with the requirements you set forth<br> though:<br>

 - I think such optimized builds might need to be done with &quot;special<br>    toolchains&quot; (these could simply be wrappers over the host compiler<br>
   passing the appropriate flags via command-line or via specs or<br>
   similar, not necessarily full blown toolchains), passing these via<br>
   something like dpkg-buildflags seems currently unreliable, as I don&#39;t<br>
   think we have full coverage in packages (neither for all compilers<br>
   available)? Although it would be better as it would centralize the<br>
   management. (For reference this is in part how rpm handles this:<br>

[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)