Hi Daniel and other Fedora experts:
I'm trying to get the m4 package to change their code. They're saying this is not POSIX
compliant change so they are resisting. See below snippet. I don't have the
background to this change to answer their questions. Is someone with this
background willing to jump onto the email thread to move forward with this?
Let me know and I'll add you to the thread. Also I told them it's not a glib
change only that Fedora is also moving in this direction but my comments
got lost in the thread.
> > I can open a defect against POSIX if we decide that is needed, but want
> > some consensus first on whether it is glibc's change that went too far,
> > or POSIX's requirements that are too restrictive for what glibc wants to do.
> Here are a couple of questions, to understand the motivation and the possible> > some consensus first on whether it is glibc's change that went too far,
> > or POSIX's requirements that are too restrictive for what glibc wants to do.
> alternative solutions to the problem:
>
> 1) As far as I understand, the issue occurs with certain x86 or x86_64
> processors.
>
> 1.1) What has been the value of MINSIGSTKSZ on x86 and x86_64 so far?
> 1.2) What value of MINSIGSTKSZ is needed for AVX-512F support?
> 1.3) Will the trend to larger MINSIGSTKSZ values continue for Intel
> processors?
On Thu, Mar 4, 2021 at 8:04 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
On Thu, Mar 04, 2021 at 07:02:27AM -0500, Carol Bouchard wrote:
> It's going to require more than removing the hack due to the following:
>
> /* Storage for the alternate signal stack. */
> static union
> {
> char buffer[SIGSTKSZ];
>
> /* These other members are for proper alignment. There's no
> standard way to guarantee stack alignment, but this seems enough
> in practice. */
> long double ld;
> long l;
> void *p;
> } alternate_signal_stack;
A "simple" option is to just stop using SIGSTKSZ here, and define
your own constant - pick it based on worst case real world SIGSTKSZ
that you'll expect. Perhaps stick in an assert in the code too, to
abort the process at runtime if the real value is larger.
A alternative solution is to stop statically allocating the
struct and instead malloc it at startup. If there's no convenient
place todo the alloc, you could possibly use an __attribute__(constructor)
function that will get invoked by the dyn loader at startup for you,
before main() even runs.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
