elf.h: Add ELFCOMPRESS_ZSTD

  Link: https://sourceware.org/pipermail/gnu-gabi/2022q2/000498.html ("New ch_type value ELFCOMPRESS_ZSTD?")
Link: https://groups.google.com/g/generic-abi/c/satyPkuMisk ("Add new ch_type value: ELFCOMPRESS_ZSTD")

---

I wish that the macro definition can catch up the upcoming
https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
The projects may choose to define the macro themselves,
but having the definition in an earlier release seems a good idea
anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
is standard and vendors can start adding support.

[1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")

From https://groups.google.com/g/generic-abi/c/9OO5vhxb00Y ("Ongoing Maintenance of the gABI"),
we should be able to define this once Cary agrees.
---
 elf/elf.h | 1 +
 1 file changed, 1 insertion(+)
  

* Fangrui Song via Libc-alpha:

> I wish that the macro definition can catch up the upcoming
> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
> The projects may choose to define the macro themselves,
> but having the definition in an earlier release seems a good idea
> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
> is standard and vendors can start adding support.
>
> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")

This looks quite backportable to me, so it should not be a release
blocker.  It's only a blocker if we apply the patch today, then we'd
have to wait until the gABI assignment actually happens as expected.

Thanks,
Florian
  

On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote:
> * Fangrui Song via Libc-alpha:
> 
>> I wish that the macro definition can catch up the upcoming
>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
>> The projects may choose to define the macro themselves,
>> but having the definition in an earlier release seems a good idea
>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
>> is standard and vendors can start adding support.
>>
>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
> 
> This looks quite backportable to me, so it should not be a release
> blocker.  It's only a blocker if we apply the patch today, then we'd
> have to wait until the gABI assignment actually happens as expected.

Agreed. This is a NACK from me as the RM until the gABI assignment happens.
  

On 2022-07-18, Carlos O'Donell via Libc-alpha wrote:
>On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote:
>> * Fangrui Song via Libc-alpha:
>>
>>> I wish that the macro definition can catch up the upcoming
>>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
>>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
>>> The projects may choose to define the macro themselves,
>>> but having the definition in an earlier release seems a good idea
>>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
>>> is standard and vendors can start adding support.
>>>
>>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
>>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
>>
>> This looks quite backportable to me, so it should not be a release
>> blocker.  It's only a blocker if we apply the patch today, then we'd
>> have to wait until the gABI assignment actually happens as expected.
>
>Agreed. This is a NACK from me as the RM until the gABI assignment happens.
>

Cary has accepted this value: https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ
(Thanks!)

Ed Maste from FreeBSD wants to define this in FreeBSD.

Shall we define it for glibc as well? :)
  

On 22/07/22 20:08, Fangrui Song via Libc-alpha wrote:
> On 2022-07-18, Carlos O'Donell via Libc-alpha wrote:
>> On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote:
>>> * Fangrui Song via Libc-alpha:
>>>
>>>> I wish that the macro definition can catch up the upcoming
>>>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
>>>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
>>>> The projects may choose to define the macro themselves,
>>>> but having the definition in an earlier release seems a good idea
>>>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
>>>> is standard and vendors can start adding support.
>>>>
>>>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
>>>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
>>>
>>> This looks quite backportable to me, so it should not be a release
>>> blocker.  It's only a blocker if we apply the patch today, then we'd
>>> have to wait until the gABI assignment actually happens as expected.
>>
>> Agreed. This is a NACK from me as the RM until the gABI assignment happens.
>>
> 
> Cary has accepted this value: https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ
> (Thanks!)
> 
> Ed Maste from FreeBSD wants to define this in FreeBSD.
> 
> Shall we define it for glibc as well? :)

I think this is ok, we are already fixing bad designs so we most likely need
more time for testing.
  

On Tue, Jul 26, 2022 at 1:24 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 22/07/22 20:08, Fangrui Song via Libc-alpha wrote:
> > On 2022-07-18, Carlos O'Donell via Libc-alpha wrote:
> >> On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote:
> >>> * Fangrui Song via Libc-alpha:
> >>>
> >>>> I wish that the macro definition can catch up the upcoming
> >>>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
> >>>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
> >>>> The projects may choose to define the macro themselves,
> >>>> but having the definition in an earlier release seems a good idea
> >>>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
> >>>> is standard and vendors can start adding support.
> >>>>
> >>>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
> >>>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
> >>>
> >>> This looks quite backportable to me, so it should not be a release
> >>> blocker.  It's only a blocker if we apply the patch today, then we'd
> >>> have to wait until the gABI assignment actually happens as expected.
> >>
> >> Agreed. This is a NACK from me as the RM until the gABI assignment happens.
> >>
> >
> > Cary has accepted this value: https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ
> > (Thanks!)
> >
> > Ed Maste from FreeBSD wants to define this in FreeBSD.
> >
> > Shall we define it for glibc as well? :)
>
> I think this is ok, we are already fixing bad designs so we most likely need
> more time for testing.

Thanks.  Now that it is approved, the commit message can be changed to
the following if you want to push it to the 2.36 release branch.

elf.h: Add ELFCOMPRESS_ZSTD

From the approved generic ABI proposal
https://groups.google.com/g/generic-abi/c/satyPkuMisk
("Add new ch_type value: ELFCOMPRESS_ZSTD").
  

On 7/26/22 16:30, Fangrui Song wrote:
> On Tue, Jul 26, 2022 at 1:24 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 22/07/22 20:08, Fangrui Song via Libc-alpha wrote:
>>> On 2022-07-18, Carlos O'Donell via Libc-alpha wrote:
>>>> On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote:
>>>>> * Fangrui Song via Libc-alpha:
>>>>>
>>>>>> I wish that the macro definition can catch up the upcoming
>>>>>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
>>>>>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
>>>>>> The projects may choose to define the macro themselves,
>>>>>> but having the definition in an earlier release seems a good idea
>>>>>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
>>>>>> is standard and vendors can start adding support.
>>>>>>
>>>>>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
>>>>>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
>>>>>
>>>>> This looks quite backportable to me, so it should not be a release
>>>>> blocker.  It's only a blocker if we apply the patch today, then we'd
>>>>> have to wait until the gABI assignment actually happens as expected.
>>>>
>>>> Agreed. This is a NACK from me as the RM until the gABI assignment happens.
>>>>
>>>
>>> Cary has accepted this value: https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ
>>> (Thanks!)
>>>
>>> Ed Maste from FreeBSD wants to define this in FreeBSD.
>>>
>>> Shall we define it for glibc as well? :)
>>
>> I think this is ok, we are already fixing bad designs so we most likely need
>> more time for testing.
> 
> Thanks.  Now that it is approved, the commit message can be changed to
> the following if you want to push it to the 2.36 release branch.
> 
> elf.h: Add ELFCOMPRESS_ZSTD
> 
> From the approved generic ABI proposal
> https://groups.google.com/g/generic-abi/c/satyPkuMisk
> ("Add new ch_type value: ELFCOMPRESS_ZSTD").

Cary,

Is there a public repo that I can use to cross-check the glibc value with
the accepted ELF gABI value?

A public repo would make the process of adding matching constants
easier because I could review what went into the public repository.

Fangrui,

Just for clarity, I don't consider this a release blocker for 2.36.
  

On 2022-07-29, Carlos O'Donell wrote:
>On 7/26/22 16:30, Fangrui Song wrote:
>> On Tue, Jul 26, 2022 at 1:24 PM Adhemerval Zanella Netto
>> <adhemerval.zanella@linaro.org> wrote:
>>>
>>>
>>>
>>> On 22/07/22 20:08, Fangrui Song via Libc-alpha wrote:
>>>> On 2022-07-18, Carlos O'Donell via Libc-alpha wrote:
>>>>> On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote:
>>>>>> * Fangrui Song via Libc-alpha:
>>>>>>
>>>>>>> I wish that the macro definition can catch up the upcoming
>>>>>>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
>>>>>>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
>>>>>>> The projects may choose to define the macro themselves,
>>>>>>> but having the definition in an earlier release seems a good idea
>>>>>>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
>>>>>>> is standard and vendors can start adding support.
>>>>>>>
>>>>>>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
>>>>>>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
>>>>>>
>>>>>> This looks quite backportable to me, so it should not be a release
>>>>>> blocker.  It's only a blocker if we apply the patch today, then we'd
>>>>>> have to wait until the gABI assignment actually happens as expected.
>>>>>
>>>>> Agreed. This is a NACK from me as the RM until the gABI assignment happens.
>>>>>
>>>>
>>>> Cary has accepted this value: https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ
>>>> (Thanks!)
>>>>
>>>> Ed Maste from FreeBSD wants to define this in FreeBSD.
>>>>
>>>> Shall we define it for glibc as well? :)
>>>
>>> I think this is ok, we are already fixing bad designs so we most likely need
>>> more time for testing.
>>
>> Thanks.  Now that it is approved, the commit message can be changed to
>> the following if you want to push it to the 2.36 release branch.
>>
>> elf.h: Add ELFCOMPRESS_ZSTD
>>
>> From the approved generic ABI proposal
>> https://groups.google.com/g/generic-abi/c/satyPkuMisk
>> ("Add new ch_type value: ELFCOMPRESS_ZSTD").
>
>Cary,
>
>Is there a public repo that I can use to cross-check the glibc value with
>the accepted ELF gABI value?
>
>A public repo would make the process of adding matching constants
>easier because I could review what went into the public repository.
>
>Fangrui,
>
>Just for clarity, I don't consider this a release blocker for 2.36.

Cary pushed a similar change to binutils-gdb
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=03d0ae791f7dca2006b924e90ee4e4944b848260

Cary mentioned it on the musl mailing list
https://www.openwall.com/lists/musl/2022/08/03/3 "Yes, this is officially approved."
  

On Thu, Aug 4, 2022 at 1:04 PM Fangrui Song <maskray@google.com> wrote:
>
> On 2022-07-29, Carlos O'Donell wrote:
> >On 7/26/22 16:30, Fangrui Song wrote:
> >> On Tue, Jul 26, 2022 at 1:24 PM Adhemerval Zanella Netto
> >> <adhemerval.zanella@linaro.org> wrote:
> >>>
> >>>
> >>>
> >>> On 22/07/22 20:08, Fangrui Song via Libc-alpha wrote:
> >>>> On 2022-07-18, Carlos O'Donell via Libc-alpha wrote:
> >>>>> On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote:
> >>>>>> * Fangrui Song via Libc-alpha:
> >>>>>>
> >>>>>>> I wish that the macro definition can catch up the upcoming
> >>>>>>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
> >>>>>>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
> >>>>>>> The projects may choose to define the macro themselves,
> >>>>>>> but having the definition in an earlier release seems a good idea
> >>>>>>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
> >>>>>>> is standard and vendors can start adding support.
> >>>>>>>
> >>>>>>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
> >>>>>>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
> >>>>>>
> >>>>>> This looks quite backportable to me, so it should not be a release
> >>>>>> blocker.  It's only a blocker if we apply the patch today, then we'd
> >>>>>> have to wait until the gABI assignment actually happens as expected.
> >>>>>
> >>>>> Agreed. This is a NACK from me as the RM until the gABI assignment happens.

Ping

> >>>>
> >>>> Cary has accepted this value: https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ
> >>>> (Thanks!)
> >>>>
> >>>> Ed Maste from FreeBSD wants to define this in FreeBSD.
> >>>>
> >>>> Shall we define it for glibc as well? :)
> >>>
> >>> I think this is ok, we are already fixing bad designs so we most likely need
> >>> more time for testing.
> >>
> >> Thanks.  Now that it is approved, the commit message can be changed to
> >> the following if you want to push it to the 2.36 release branch.
> >>
> >> elf.h: Add ELFCOMPRESS_ZSTD
> >>
> >> From the approved generic ABI proposal
> >> https://groups.google.com/g/generic-abi/c/satyPkuMisk
> >> ("Add new ch_type value: ELFCOMPRESS_ZSTD").
> >
> >Cary,
> >
> >Is there a public repo that I can use to cross-check the glibc value with
> >the accepted ELF gABI value?
> >
> >A public repo would make the process of adding matching constants
> >easier because I could review what went into the public repository.
> >
> >Fangrui,
> >
> >Just for clarity, I don't consider this a release blocker for 2.36.
>
> Cary pushed a similar change to binutils-gdb
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=03d0ae791f7dca2006b924e90ee4e4944b848260
>
> Cary mentioned it on the musl mailing list
> https://www.openwall.com/lists/musl/2022/08/03/3 "Yes, this is officially approved."
  

* Fangrui Song via Libc-alpha:

> Link: https://sourceware.org/pipermail/gnu-gabi/2022q2/000498.html ("New ch_type value ELFCOMPRESS_ZSTD?")
> Link: https://groups.google.com/g/generic-abi/c/satyPkuMisk ("Add new ch_type value: ELFCOMPRESS_ZSTD")
>
> ---
>
> I wish that the macro definition can catch up the upcoming
> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that
> projects can expect the value ELFCOMPRESS_ZSTD from elf.h.
> The projects may choose to define the macro themselves,
> but having the definition in an earlier release seems a good idea
> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD
> is standard and vendors can start adding support.
>
> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html
> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.")
>
> From https://groups.google.com/g/generic-abi/c/9OO5vhxb00Y ("Ongoing Maintenance of the gABI"),
> we should be able to define this once Cary agrees.
> ---
>  elf/elf.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/elf/elf.h b/elf/elf.h
> index 2b5c2c5fb6..f6ae2348a9 100644
> --- a/elf/elf.h
> +++ b/elf/elf.h
> @@ -505,6 +505,7 @@ typedef struct
>  
>  /* Legal values for ch_type (compression algorithm).  */
>  #define ELFCOMPRESS_ZLIB	1	   /* ZLIB/DEFLATE algorithm.  */
> +#define ELFCOMPRESS_ZSTD	2	   /* Zstandard algorithm.  */
>  #define ELFCOMPRESS_LOOS	0x60000000 /* Start of OS-specific.  */
>  #define ELFCOMPRESS_HIOS	0x6fffffff /* End of OS-specific.  */
>  #define ELFCOMPRESS_LOPROC	0x70000000 /* Start of processor-specific.  */

Could you repost this with the actual commit message you intend to use?

Thanks,
Florian