Re: as cannot do endbr64 instructions (too old)
Please send it to tech@
On 2024/01/10 13:18, Lorenz (xha) wrote:
> On Wed, Jan 03, 2024 at 08:50:43AM +0100, Lorenz (xha) wrote:
> > On Tue, Jan 02, 2024 at 08:32:00PM -, Stuart Henderson wrote:
> > > I can't say. Though I doubt there would much objection if it's clean and
> > > not a copy of a GPLv3-licensed upstream commit.
> >
> > what about this?
> >
> > i am not sure about the situation on arm64. it looks like newer gnu
> > assemblers don't like bti instructions unless explicitly enabled.
> > llvm seems to be using hint #34 for compatibility.
> >
> > is /usr/bin/as the GNU assembler on arm64 aswell?
> >
> > Index: include/opcode/i386.h
> > ===
> > RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/opcode/i386.h,v
> > retrieving revision 1.11
> > diff -C5 -r1.11 i386.h
> > *** include/opcode/i386.h 9 Sep 2018 21:59:43 - 1.11
> > --- include/opcode/i386.h 3 Jan 2024 07:35:49 -
> > ***
> > *** 1532,1541
> > --- 1532,1545
> >
> > /* Intel PCID extension */
> > {"invpcid", 2, 0x660f3882, X, CpuNEW|CpuNo64,
> > Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> > BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg32 } },
> > {"invpcid", 2, 0x660f3882, X, CpuNEW|Cpu64,
> > Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> > BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg64 } },
> >
> > + /* Intel Indirect Branch Tracking extensions */
> > + {"endbr64", 0, 0xF30F1E, 0xFA, Cpu64, NoSuf|ImmExt, { 0, 0, 0 } },
> > + {"endbr32", 0, 0xF30F1E, 0xFB, CpuNo64, NoSuf|ImmExt, { 0, 0, 0 } },
> > +
> > /* sentinel */
> > {NULL, 0, 0, 0, 0, 0, { 0, 0, 0} }
> > };
> > #undef X
> > #undef NoSuf
> >
>
> can someone take a look at this and maby commit if it is OK? i
> removed the endbr32 instruction from the patch because i don't think
> it will ever be needed on openbsd.
>
> Index: gnu/usr.bin/binutils-2.17/include/opcode/i386.h
> ===
> RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/opcode/i386.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 i386.h
> --- gnu/usr.bin/binutils-2.17/include/opcode/i386.h 9 Sep 2018 21:59:43
> - 1.11
> +++ gnu/usr.bin/binutils-2.17/include/opcode/i386.h 10 Jan 2024 12:15:36
> -
> @@ -1534,6 +1534,9 @@ static const template i386_optab[] =
> {"invpcid", 2, 0x660f3882, X, CpuNEW|CpuNo64,
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg32 } },
> {"invpcid", 2, 0x660f3882, X, CpuNEW|Cpu64,
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg64 } },
>
> +/* Intel Indirect Branch Tracking extensions */
> +{"endbr64", 0, 0xF30F1E, 0xFA, Cpu64, NoSuf|ImmExt, { 0, 0, 0 } },
> +
> /* sentinel */
> {NULL, 0, 0, 0, 0, 0, { 0, 0, 0} }
> };
Re: as cannot do endbr64 instructions (too old)
On Wed, Jan 03, 2024 at 08:50:43AM +0100, Lorenz (xha) wrote:
> On Tue, Jan 02, 2024 at 08:32:00PM -, Stuart Henderson wrote:
> > I can't say. Though I doubt there would much objection if it's clean and
> > not a copy of a GPLv3-licensed upstream commit.
>
> what about this?
>
> i am not sure about the situation on arm64. it looks like newer gnu
> assemblers don't like bti instructions unless explicitly enabled.
> llvm seems to be using hint #34 for compatibility.
>
> is /usr/bin/as the GNU assembler on arm64 aswell?
>
> Index: include/opcode/i386.h
> ===
> RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/opcode/i386.h,v
> retrieving revision 1.11
> diff -C5 -r1.11 i386.h
> *** include/opcode/i386.h 9 Sep 2018 21:59:43 - 1.11
> --- include/opcode/i386.h 3 Jan 2024 07:35:49 -
> ***
> *** 1532,1541
> --- 1532,1545
>
> /* Intel PCID extension */
> {"invpcid", 2, 0x660f3882, X, CpuNEW|CpuNo64,
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg32 } },
> {"invpcid", 2, 0x660f3882, X, CpuNEW|Cpu64,
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg64 } },
>
> + /* Intel Indirect Branch Tracking extensions */
> + {"endbr64", 0, 0xF30F1E, 0xFA, Cpu64, NoSuf|ImmExt, { 0, 0, 0 } },
> + {"endbr32", 0, 0xF30F1E, 0xFB, CpuNo64, NoSuf|ImmExt, { 0, 0, 0 } },
> +
> /* sentinel */
> {NULL, 0, 0, 0, 0, 0, { 0, 0, 0} }
> };
> #undef X
> #undef NoSuf
>
can someone take a look at this and maby commit if it is OK? i
removed the endbr32 instruction from the patch because i don't think
it will ever be needed on openbsd.
Index: gnu/usr.bin/binutils-2.17/include/opcode/i386.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/opcode/i386.h,v
retrieving revision 1.11
diff -u -p -r1.11 i386.h
--- gnu/usr.bin/binutils-2.17/include/opcode/i386.h 9 Sep 2018 21:59:43
- 1.11
+++ gnu/usr.bin/binutils-2.17/include/opcode/i386.h 10 Jan 2024 12:15:36
-
@@ -1534,6 +1534,9 @@ static const template i386_optab[] =
{"invpcid", 2, 0x660f3882, X, CpuNEW|CpuNo64,
Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg32 } },
{"invpcid", 2, 0x660f3882, X, CpuNEW|Cpu64,
Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg64 } },
+/* Intel Indirect Branch Tracking extensions */
+{"endbr64", 0, 0xF30F1E, 0xFA, Cpu64, NoSuf|ImmExt, { 0, 0, 0 } },
+
/* sentinel */
{NULL, 0, 0, 0, 0, 0, { 0, 0, 0} }
};
Re: as cannot do endbr64 instructions (too old)
On Wed, Jan 03, 2024 at 08:50:43AM +0100, Lorenz (xha) wrote:
> On Tue, Jan 02, 2024 at 08:32:00PM -, Stuart Henderson wrote:
> > I can't say. Though I doubt there would much objection if it's clean and
> > not a copy of a GPLv3-licensed upstream commit.
>
> what about this?
>
> i am not sure about the situation on arm64. it looks like newer gnu
> assemblers don't like bti instructions unless explicitly enabled.
> llvm seems to be using hint #34 for compatibility.
>
> is /usr/bin/as the GNU assembler on arm64 aswell?
There is no as(1) installed on arm64.
-Otto
>
> Index: include/opcode/i386.h
> ===
> RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/opcode/i386.h,v
> retrieving revision 1.11
> diff -C5 -r1.11 i386.h
> *** include/opcode/i386.h 9 Sep 2018 21:59:43 - 1.11
> --- include/opcode/i386.h 3 Jan 2024 07:35:49 -
> ***
> *** 1532,1541
> --- 1532,1545
>
> /* Intel PCID extension */
> {"invpcid", 2, 0x660f3882, X, CpuNEW|CpuNo64,
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg32 } },
> {"invpcid", 2, 0x660f3882, X, CpuNEW|Cpu64,
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg64 } },
>
> + /* Intel Indirect Branch Tracking extensions */
> + {"endbr64", 0, 0xF30F1E, 0xFA, Cpu64, NoSuf|ImmExt, { 0, 0, 0 } },
> + {"endbr32", 0, 0xF30F1E, 0xFB, CpuNo64, NoSuf|ImmExt, { 0, 0, 0 } },
> +
> /* sentinel */
> {NULL, 0, 0, 0, 0, 0, { 0, 0, 0} }
> };
> #undef X
> #undef NoSuf
>
Re: as cannot do endbr64 instructions (too old)
On Tue, Jan 02, 2024 at 08:32:00PM -, Stuart Henderson wrote:
> I can't say. Though I doubt there would much objection if it's clean and
> not a copy of a GPLv3-licensed upstream commit.
what about this?
i am not sure about the situation on arm64. it looks like newer gnu
assemblers don't like bti instructions unless explicitly enabled.
llvm seems to be using hint #34 for compatibility.
is /usr/bin/as the GNU assembler on arm64 aswell?
Index: include/opcode/i386.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/opcode/i386.h,v
retrieving revision 1.11
diff -C5 -r1.11 i386.h
*** include/opcode/i386.h 9 Sep 2018 21:59:43 - 1.11
--- include/opcode/i386.h 3 Jan 2024 07:35:49 -
***
*** 1532,1541
--- 1532,1545
/* Intel PCID extension */
{"invpcid", 2, 0x660f3882, X, CpuNEW|CpuNo64,
Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg32 } },
{"invpcid", 2, 0x660f3882, X, CpuNEW|Cpu64,
Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, {
BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg64 } },
+ /* Intel Indirect Branch Tracking extensions */
+ {"endbr64", 0, 0xF30F1E, 0xFA, Cpu64, NoSuf|ImmExt, { 0, 0, 0 } },
+ {"endbr32", 0, 0xF30F1E, 0xFB, CpuNo64, NoSuf|ImmExt, { 0, 0, 0 } },
+
/* sentinel */
{NULL, 0, 0, 0, 0, 0, { 0, 0, 0} }
};
#undef X
#undef NoSuf
Re: as cannot do endbr64 instructions (too old)
On 2024-01-02, Lorenz (xha) wrote: > what is the reason to only include GPLv2 and not GPLv3? The new license terms are not wanted for the base OS. As with GCC, a newer GPLv3 version is available in ports. > that "as" doesn't support modern instructions is starting to cause > all sorts of nasty problems. the compiler backend of hare, QBE, > recently had a patch accepted which adds IBT/BTI support and i > prepared the stdlib to be able to deal with IBT/BTI. > > however, the patch was reverted yesterday with the reason that the > standard openbsd toolchain doesn't support it. i would need to patch > QBE to accept a cfi flag (i don't even know if it'd get accepted), > which, again, would introduce new workarounds in hare for openbsd. You could perhaps encode the bytes instead, like openssl does specifically so it will work on other OS with old binutils too.. 0xf3,0x0f,0x1e,0xfa > if updating "as" is really not an option, would a patch adding support > for endbr64 and the BTI equivilant be accepted? I can't say. Though I doubt there would much objection if it's clean and not a copy of a GPLv3-licensed upstream commit. -- Please keep replies on the mailing list.
Re: as cannot do endbr64 instructions (too old)
On Tue, Jan 02, 2024 at 11:51:48AM +0100, Otto Moerbeek wrote: > On Tue, Jan 02, 2024 at 08:56:55PM +1100, Alexis wrote: > > > > > "Lorenz (xha)" writes: > > > > > On Mon, Jan 01, 2024 at 08:47:07PM +1100, Alexis wrote: > > > > > > > > "Lorenz (xha)" writes: > > > > > > > > > just out of couriosity, why is "as" in the base system if it > is > > > > > outdated and is updating it an option? > > > > > > > > i presume it's due to subsequent versions being licensed under later > > > > versions of the GPL, but i'd be happy to be corrected on this point. > > > > > > i couldn't find any discussions on why the later versions are not > > > acceptable in the base system. are there any? > > WRT the GPL the policy boils down to: > > - We do not want new software using GPL in our tree > - For existing software we only allow GPL2. For projects that switched > license like gcc, we stick at the latest GPL2 version and try to > replace the software. what is the reason to only include GPLv2 and not GPLv3? that "as" doesn't support modern instructions is starting to cause all sorts of nasty problems. the compiler backend of hare, QBE, recently had a patch accepted which adds IBT/BTI support and i prepared the stdlib to be able to deal with IBT/BTI. however, the patch was reverted yesterday with the reason that the standard openbsd toolchain doesn't support it. i would need to patch QBE to accept a cfi flag (i don't even know if it'd get accepted), which, again, would introduce new workarounds in hare for openbsd. if updating "as" is really not an option, would a patch adding support for endbr64 and the BTI equivilant be accepted?
Re: as cannot do endbr64 instructions (too old)
On Tue, Jan 02, 2024 at 01:34:14PM +0100, Lorenz (xha) wrote: > as cannot be used correctly anymore (at least on amd64) because it is > missing the newer instructions. It's perfectly usable for assembling any handwritten asm code that doesn't use the newer instructions. I use the 'as' in base on a regular basis precisely for this. It's not just hand written asm either, we have our own compiler that spits out X86 asm source which is assembled with base 'as' and linked with base 'ld' to produce static binaries. > would it make sense to remove it? No.
Re: as cannot do endbr64 instructions (too old)
On Tue, Jan 02, 2024 at 11:51:48AM +0100, Otto Moerbeek wrote: > Dunno what haoppened to as(1) specifically. But as we do not use > standalone as(1) for our own builds, it does not get a lot of > attention (in additional to the potential licensing issues). as cannot be used correctly anymore (at least on amd64) because it is missing the newer instructions. would it make sense to remove it? anyways, i think i found a way to assemble mulitple input files using some concat hacks. thanks.
Re: as cannot do endbr64 instructions (too old)
On Tue, Jan 02, 2024 at 08:56:55PM +1100, Alexis wrote: > > "Lorenz (xha)" writes: > > > On Mon, Jan 01, 2024 at 08:47:07PM +1100, Alexis wrote: > > > > > > "Lorenz (xha)" writes: > > > > > > > just out of couriosity, why is "as" in the base system if it > is > > > > outdated and is updating it an option? > > > > > > i presume it's due to subsequent versions being licensed under later > > > versions of the GPL, but i'd be happy to be corrected on this point. > > > > i couldn't find any discussions on why the later versions are not > > acceptable in the base system. are there any? WRT the GPL the policy boils down to: - We do not want new software using GPL in our tree - For existing software we only allow GPL2. For projects that switched license like gcc, we stick at the latest GPL2 version and try to replace the software. > > There's a discussion about GPL software in base at > https://www.openbsd.org/policy.html, although it doesn't mention GPL > versions: > > > The GNU Public License and licenses modeled on it impose the restriction > > that source code must be distributed or made available for all works > > that are derivatives of the GNU copyrighted code. > > > > While this may superficially look like a noble strategy, it is a > > condition that is typically unacceptable for commercial use of software. > > So in practice, it usually ends up hindering free sharing and reuse of > > code and ideas rather than encouraging it. As a consequence, no > > additional software bound by the GPL terms will be considered for > > inclusion into the OpenBSD base system. > > > > For historical reasons, the OpenBSD base system still includes the > > following GPL-licensed components: the GNU compiler collection (GCC) > > with supporting binutils and libraries, GNU CVS, GNU texinfo, the > > mkhybrid file system creation tool, and the readline library. > > Replacement by equivalent, more freely licensed tools is a long-term > > desideratum. > > But, again, someone else will have to describe what's happening with 'as' > specifically; i'm not an OpenBSD dev myself. My speculation about the GPL > version potentially being involved comes from Apple not including versions > of software whose license had been changed from GPL2 to GPL3 (such that e.g. > versions of macOS prior to Catalina only included GNU Emacs 22). > > > Alexis. Dunno what haoppened to as(1) specifically. But as we do not use standalone as(1) for our own builds, it does not get a lot of attention (in additional to the potential licensing issues). -Otto
Re: as cannot do endbr64 instructions (too old)
"Lorenz (xha)" writes: On Mon, Jan 01, 2024 at 08:47:07PM +1100, Alexis wrote: "Lorenz (xha)" writes: > just out of couriosity, why is "as" in the base system if it > is > outdated and is updating it an option? i presume it's due to subsequent versions being licensed under later versions of the GPL, but i'd be happy to be corrected on this point. i couldn't find any discussions on why the later versions are not acceptable in the base system. are there any? There's a discussion about GPL software in base at https://www.openbsd.org/policy.html, although it doesn't mention GPL versions: The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code. While this may superficially look like a noble strategy, it is a condition that is typically unacceptable for commercial use of software. So in practice, it usually ends up hindering free sharing and reuse of code and ideas rather than encouraging it. As a consequence, no additional software bound by the GPL terms will be considered for inclusion into the OpenBSD base system. For historical reasons, the OpenBSD base system still includes the following GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils and libraries, GNU CVS, GNU texinfo, the mkhybrid file system creation tool, and the readline library. Replacement by equivalent, more freely licensed tools is a long-term desideratum. But, again, someone else will have to describe what's happening with 'as' specifically; i'm not an OpenBSD dev myself. My speculation about the GPL version potentially being involved comes from Apple not including versions of software whose license had been changed from GPL2 to GPL3 (such that e.g. versions of macOS prior to Catalina only included GNU Emacs 22). Alexis.
Re: as cannot do endbr64 instructions (too old)
On Mon, Jan 01, 2024 at 08:47:07PM +1100, Alexis wrote: > > "Lorenz (xha)" writes: > > > just out of couriosity, why is "as" in the base system if it is > > outdated and is updating it an option? > > i presume it's due to subsequent versions being licensed under later > versions of the GPL, but i'd be happy to be corrected on this point. i couldn't find any discussions on why the later versions are not acceptable in the base system. are there any? also, shouldn't it be removed it it does not work correctly anymore?
Re: as cannot do endbr64 instructions (too old)
"Lorenz (xha)" writes: just out of couriosity, why is "as" in the base system if it is outdated and is updating it an option? i presume it's due to subsequent versions being licensed under later versions of the GPL, but i'd be happy to be corrected on this point. Alexis.
Re: as cannot do endbr64 instructions (too old)
On Mon, Jan 01, 2024 at 10:04:07AM +0100, Otto Moerbeek wrote: > On Mon, Jan 01, 2024 at 10:00:34AM +0100, Lorenz (xha) wrote: > > > On Sun, Dec 31, 2023 at 03:39:14PM +0100, Otto Moerbeek wrote: > > > On Sun, Dec 31, 2023 at 04:51:14AM +0100, Lorenz (xha) wrote: > > > > > > > hi misc@, > > > > > > > > like the subject says, `as` in the base system cannot do endbr64 > > > > instructions. should it be updated? > > > > > > > > background: i am maintaining hare for openbsd and we always have > > > > to install "gas" from the "binutils" package because the normal one > > > > is too old. i'd be nice if we don't depend on any packages from > > > > ports and don't have some specific workarounds in hare just for > > > > openbsd because "as" is too old. > > > > > > > > if updating "as" is not an option, is there a way to invoke the > > > > llvm assembler directly in the base system? > > > > > > > > thanks. > > > > > > > > - lorenz > > > > > > > > > > cc will assesmbly a .s or .S file. > > > > > > > it looks like cc cannot combine multiple assembly files into one. this > > is a simplified version of the command line: > > > > $(AS) -o example.o example_a.s example_b.s > > > > it works when defining "AS = gas", but not when doing "AS = cc -c": > > > > "cc: error: cannot specify -o when generating multiple output files" > > > > is there a way to do this with llvm? > > Assemble the files individually and link them? Concat and assemble? both should work but would require big changes in the way hare is built and are not really an option, considering that it works on all other platforms without these changes. i'd like to not have openbsd-specific workarounds. just out of couriosity, why is "as" in the base system if it is outdated and is updating it an option?
Re: as cannot do endbr64 instructions (too old)
On Mon, Jan 01, 2024 at 10:00:34AM +0100, Lorenz (xha) wrote: > On Sun, Dec 31, 2023 at 03:39:14PM +0100, Otto Moerbeek wrote: > > On Sun, Dec 31, 2023 at 04:51:14AM +0100, Lorenz (xha) wrote: > > > > > hi misc@, > > > > > > like the subject says, `as` in the base system cannot do endbr64 > > > instructions. should it be updated? > > > > > > background: i am maintaining hare for openbsd and we always have > > > to install "gas" from the "binutils" package because the normal one > > > is too old. i'd be nice if we don't depend on any packages from > > > ports and don't have some specific workarounds in hare just for > > > openbsd because "as" is too old. > > > > > > if updating "as" is not an option, is there a way to invoke the > > > llvm assembler directly in the base system? > > > > > > thanks. > > > > > > - lorenz > > > > > > > cc will assesmbly a .s or .S file. > > > > it looks like cc cannot combine multiple assembly files into one. this > is a simplified version of the command line: > > $(AS) -o example.o example_a.s example_b.s > > it works when defining "AS = gas", but not when doing "AS = cc -c": > > "cc: error: cannot specify -o when generating multiple output files" > > is there a way to do this with llvm? Assemble the files individually and link them? Concat and assemble? > > why is "as" so old? -Otto
Re: as cannot do endbr64 instructions (too old)
On Sun, Dec 31, 2023 at 03:39:14PM +0100, Otto Moerbeek wrote: > On Sun, Dec 31, 2023 at 04:51:14AM +0100, Lorenz (xha) wrote: > > > hi misc@, > > > > like the subject says, `as` in the base system cannot do endbr64 > > instructions. should it be updated? > > > > background: i am maintaining hare for openbsd and we always have > > to install "gas" from the "binutils" package because the normal one > > is too old. i'd be nice if we don't depend on any packages from > > ports and don't have some specific workarounds in hare just for > > openbsd because "as" is too old. > > > > if updating "as" is not an option, is there a way to invoke the > > llvm assembler directly in the base system? > > > > thanks. > > > > - lorenz > > > > cc will assesmbly a .s or .S file. > it looks like cc cannot combine multiple assembly files into one. this is a simplified version of the command line: $(AS) -o example.o example_a.s example_b.s it works when defining "AS = gas", but not when doing "AS = cc -c": "cc: error: cannot specify -o when generating multiple output files" is there a way to do this with llvm? why is "as" so old?
Re: as cannot do endbr64 instructions (too old)
Ah, only disasm support was added to binutils.
Re: as cannot do endbr64 instructions (too old)
On Sun, Dec 31, 2023 at 09:55:25AM -0700, Theo de Raadt wrote: > That's curious. > > We never invoke as directly these days. > > It feels like an upstream llvm bug, and I say that because noone else has > embraced BTI/IBT as much as we have, everyone else is still considering it > a thing for specific applications or the future. /usr/bin/as is stil GNU as (at least on amd64). -Otto > > Lorenz (xha) wrote: > > > hi misc@, > > > > like the subject says, `as` in the base system cannot do endbr64 > > instructions. should it be updated? > > > > background: i am maintaining hare for openbsd and we always have > > to install "gas" from the "binutils" package because the normal one > > is too old. i'd be nice if we don't depend on any packages from > > ports and don't have some specific workarounds in hare just for > > openbsd because "as" is too old. > > > > if updating "as" is not an option, is there a way to invoke the > > llvm assembler directly in the base system? > > > > thanks. > > > > - lorenz > > >
Re: as cannot do endbr64 instructions (too old)
That's curious. We never invoke as directly these days. It feels like an upstream llvm bug, and I say that because noone else has embraced BTI/IBT as much as we have, everyone else is still considering it a thing for specific applications or the future. Lorenz (xha) wrote: > hi misc@, > > like the subject says, `as` in the base system cannot do endbr64 > instructions. should it be updated? > > background: i am maintaining hare for openbsd and we always have > to install "gas" from the "binutils" package because the normal one > is too old. i'd be nice if we don't depend on any packages from > ports and don't have some specific workarounds in hare just for > openbsd because "as" is too old. > > if updating "as" is not an option, is there a way to invoke the > llvm assembler directly in the base system? > > thanks. > > - lorenz >
Re: as cannot do endbr64 instructions (too old)
On Sun, Dec 31, 2023 at 04:51:14AM +0100, Lorenz (xha) wrote: > hi misc@, > > like the subject says, `as` in the base system cannot do endbr64 > instructions. should it be updated? > > background: i am maintaining hare for openbsd and we always have > to install "gas" from the "binutils" package because the normal one > is too old. i'd be nice if we don't depend on any packages from > ports and don't have some specific workarounds in hare just for > openbsd because "as" is too old. > > if updating "as" is not an option, is there a way to invoke the > llvm assembler directly in the base system? > > thanks. > > - lorenz > cc will assesmbly a .s or .S file. -Otto
