public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Jan Kratochvil <jkratochvil@azul.com>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
	libc-alpha@sourceware.org,  Anton Kozlov <akozlov@azul.com>
Subject: Re: [PATCH] RFC: Provide a function to reset IFUNC PLTs
Date: Mon, 13 Mar 2023 14:59:26 +0100	[thread overview]
Message-ID: <87sfe8rbup.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <ZAnDyDi3QQ4dM80K@host1.jankratochvil.net> (Jan Kratochvil's message of "Thu, 9 Mar 2023 19:32:24 +0800")

* Jan Kratochvil:

> On Wed, 08 Mar 2023 21:04:59 +0800, Adhemerval Zanella Netto wrote:
>> But as Florian has said, fixing on glibc won't work consistently on other
>> libraries that uses cpuid instruction.
>
> In Java world the other libraries (in general, there are some JNI exceptions)
> do not matter as they are a Java code JIT-compiled by JVM.

That's not really true for GUI applications, which use quite a few
system libraries.  Even in headless applications, font rendering code
may be loaded, say for PDF generation.  If system versions are used,
that pulls in compression libraries and PCRE, and those tend to have
CPUID-based switching, too (but perhaps not in the form of IFUNC
resolvers).  This is just on x86-64—on aarch64, you will have to deal
with the outline atomics most distributions use.

I suggest you base your OpenJDK work on the OpenJDK musl port.  This
way, you can carefully control what you build and how you build it, and
also make it impossible to pick up system libraries by accident.  And
static JNI would be a good fit if you do not expect JNI to be used
anyway.

Thanks,
Florian


  parent reply	other threads:[~2023-03-13 13:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06  8:04 Jan Kratochvil
2023-03-07  8:40 ` Florian Weimer
2023-03-07 13:07   ` Adhemerval Zanella Netto
2023-03-08 10:21     ` Jan Kratochvil
2023-03-08 13:04       ` Adhemerval Zanella Netto
2023-03-09 11:32         ` Jan Kratochvil
2023-03-09 15:47           ` Adhemerval Zanella Netto
2023-03-09 17:43             ` Adhemerval Zanella Netto
2023-03-16 14:38             ` Jan Kratochvil
2023-03-20 16:47               ` Adhemerval Zanella Netto
2023-03-29 12:12                 ` Jan Kratochvil
2023-03-29 13:14                   ` Adhemerval Zanella Netto
2023-03-13 13:59           ` Florian Weimer [this message]
2023-03-14 12:55             ` Jan Kratochvil
2023-03-14 14:49               ` Florian Weimer
2023-03-14 15:06                 ` Jan Kratochvil
2023-03-08 10:23   ` Jan Kratochvil
2023-03-08 10:44     ` Florian Weimer
2023-03-08 11:03       ` Jan Kratochvil

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=87sfe8rbup.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=akozlov@azul.com \
    --cc=jkratochvil@azul.com \
    --cc=libc-alpha@sourceware.org \
    /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).