[PATCH] elf: Add la_objsearch2 with lmid parameter for rtld-audit [BZ #34093]

[Frederic Berat]

On Wed, Sep 23, 2026 at 10:27 PM DJ Delorie <dj@redhat.com> wrote:

> On Wed, Sep 23, 2026 at 3:55 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
> > Right, but then you move the version check from glibc to the audit
> > module itself.  I am not sure if this is a better semantic.
>
> I think there's a couple of scenarios to consider:
>
> 1. Existing auditors will request the old LAV_CURRENT (say, 2).  New
>    glibc will need to support that version.  sysdeps/generic has the
>    right logic, but aarch64 and loongarch will need a range check
>    (currently they use ==) since the previous version is incompatible.
>
> 2. A new auditor that allows but does not require the new function can
>    return the OLD version (LAV_CURRENT-1) and dynamically adapt to
>    whatever callbacks happen.
>
> 3. An auditor requires the new callback, is built with the new
>    headers, and will fail to load on old glibc's.
>
> 4. A new auditor wants the old callback, but builds with the new
>    LAV_CURRENT.
>
> I think bumping LAV_CURRENT will work in all cases.  Not bumping it
> works for 1 and 2 but not 3.
>
> Case 4 requires glibc internals to detect which is requested, which
> Fred's patch does.
>
> Case 2 is more flexible for auditor deployers but is trickier to code,
> especially as the LAV_CURRENT values are inconsistent across targets.
>
> The only time we MUST bump LAV_CURRENT is when an existing callback
> changes in a way that breaks existing auditors.
>
>
Based on Ben Woodard comment, I could also extend la_obsearch instead of
creating the new interface.
I went for a new interface because I thought it was better/simpler, but I
don't have a strong opinion about it.
Any feedback on that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260924/8f4da8f3/attachment.htm>