public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Luca Boccassi <bluca@debian.org>
Cc: elfutils-devel@sourceware.org, Tom Stellard <tstellar@redhat.com>
Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note
Date: Mon, 28 Mar 2022 11:57:52 +0200	[thread overview]
Message-ID: <d625bea47751228a306571efa733de7d2a617c12.camel@klomp.org> (raw)
In-Reply-To: <976e9368e62fb585b9084a7c200e55615588a123.camel@debian.org>

Hi Luca,

On Sat, 2022-03-26 at 18:19 +0000, Luca Boccassi wrote:
> > Already working on the updated script, the native type is exactly
> > the
> > approach I was taking, this works fine on a Debian machine on s390x
> > (and also on x86_64), eg:
> > 
> > -        BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of
> > Owner including NUL */
> > -        BYTE(0x47) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of
> > Value including NUL */
> > -        BYTE(0x7e) BYTE(0x1a) BYTE(0xfe) BYTE(0xca) /* Note ID */
> > +        LONG(0x04)                                  /* Length of
> > Owner including NUL */
> > +        LONG(0x0047)                                /* Length of
> > Value including NUL */
> > +        LONG(0xcafe1a7e)                            /* Note ID */
> > 
> > The rest of the fields are C strings so no change needed, I
> > believe.
> > 
> > Does this look right to you as well?
> 
> Here's the fix:
> 
> https://src.fedoraproject.org/rpms/package-notes/pull-request/3#
> 
> Now it's up to the Fedora folks what to do with it. I tested the
> updated script on Debian x86_64 and s390x, and it all works as
> intended. Sorry again for the breakage!

Yes, that looks correct. Note that the example on 
https://systemd.io/COREDUMP_PACKAGE_METADATA/ also uses BYTEs for
everything, instead of LONGs for the namesz, descsz and type words.

This also seems to make sure everything is aligned (at 4 bytes). An ELF
note is defined as an array of (4 byte) words. Where the first 3
(n_namesz, n_descsz, n_type) have a special interpretation. Your name
string is also exactly 4 bytes "FDO\0", so you don't need any extra
padding to make the start of the descriptor be aligned. And since you
don't add any other notes to the section you don't need to explicitly
pad the description. The linker should take care of that in case it
merges note sections/segments.

Still I would really recommend trying to add native support to linkers
for package notes, just like they support build-ids by default. That
also makes it easier for the linker to simply merge the notes. Trying
to do this with inserting a linker script really feels very fragile.

Cheers,

Mark

  reply	other threads:[~2022-03-28  9:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19  0:31 [PATCH] " luca.boccassi
2021-11-21 16:33 ` Mark Wielaard
2021-11-21 19:54   ` Luca Boccassi
2021-11-21 19:43 ` [PATCH v2] " luca.boccassi
2021-11-25 17:02   ` Luca Boccassi
2021-11-30 11:25     ` Mark Wielaard
2021-11-30 12:37       ` Luca Boccassi
2021-11-30 16:23       ` Frank Ch. Eigler
2021-11-30 16:49         ` Florian Weimer
2021-11-30 20:04           ` Mark Wielaard
2021-12-02 15:16           ` Frank Ch. Eigler
2021-12-02 15:44             ` Florian Weimer
2021-12-05 17:36       ` Mark Wielaard
2022-03-24 23:14         ` Mark Wielaard
2022-03-24 23:14           ` [PATCH 1/3] libelf: Sync elf.h from glibc Mark Wielaard
2022-03-24 23:14           ` [PATCH 2/3] libebl: recognize FDO Packaging Metadata ELF note Mark Wielaard
2022-03-24 23:14           ` [PATCH 3/3] elflint: Recognize NT_FDO_PACKAGING_METADATA Mark Wielaard
2022-03-25 11:17           ` [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note Luca Boccassi
2022-03-25 13:39             ` Mark Wielaard
2022-03-25 13:52               ` Luca Boccassi
2022-03-25 14:47                 ` Mark Wielaard
2022-03-25 14:55                   ` Luca Boccassi
2022-03-26 16:33                     ` Mark Wielaard
2022-03-26 16:57                       ` Luca Boccassi
2022-03-26 18:19                         ` Luca Boccassi
2022-03-28  9:57                           ` Mark Wielaard [this message]
2022-03-28 10:41                             ` Luca Boccassi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d625bea47751228a306571efa733de7d2a617c12.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=bluca@debian.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=tstellar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).