On Tue, May 26, 2026 at 3:56 PM H.J. Lu <[email protected]> wrote:
>
> On Wed, May 27, 2026 at 6:41 AM Iain Sandoe <[email protected]> wrote:
> >
> >
> >
> > > On 26 May 2026, at 22:35, H.J. Lu <[email protected]> wrote:
> > >
> > > On Tue, May 26, 2026 at 11:19 PM Iain Sandoe <[email protected]>
> > > wrote:
> > >>
> > >> HJ,
> > >>
> > >> Bootstrap on 32b Darwin (and 64b Darwin with 32b multilib) is still
> > >> broken after
> > >> more than three weeks,
> > >>
> > >> It is reasonable to have a temporary break if there is a trivial typo or
> > >> other fix
> > >> that can be applied in a timely manner.
> > >>
> > >> However, in this case, it seems your initial design needed some
> > >> amendment,
> > >> and that means a more complex fix is needed - which needs additional
> > >> review.
> > >>
> > >> Today I now faced two concurrent bootstrap breaks on some platform
> > >> versions
> > >> - this is just consuming time in a non-constructive manner.
> > >
> > > It only shows that maintainers pay no attention to Darwin. In the
> > > meantime,
> > > you can submit a very simple libssp patch to fix Darwin build by changing
> > > __stack_chk_guard to unsigned long for Darwin.
> >
> > I find this unbelievable, and cannot think of any other maintainer who would
> > leave a regulalry-tested platform broken for weeks, and then try pass the
> > blame
> > to reviewers for not being quick enough review band aid upon band aid.
> >
> > The responsibility for producing good reviewed patches lies with you - not
> > with other maintainers for platforms you break with bad patches, and not
> > with
> > reviewers who might have more pressing things to address.
>
> I submitted a fix and suggested one line change to address Darwin build.
> You choose to ignore my suggestion.
>
> > I would be very disappointed if this is what is considered to be “good
> > community” behaviour.
> >
> > Iain
> > ** even with all your patches applied the testcases need work - it is not
> > at all
> > helpful that you leave it to others to finish off your incomplete work.
> >
>
> I submitted patches to address regressions. Some newly added tests failed
> due to the existing libssp implementation bug. You can xfail them if ssp
> isn't
> provided in libc.
So I am going to step into this mess and explain how this mess came
about in the first place.
Here is the situation and the problem is stack_protect_guard looks
like a mess to begin with.
GCC documented it this way: `The type of this variable must be
@code{ptr_type_node}.`
So libssp followed this. BUT glibc, and many other libc's didn't
follow this document part. glibc (and many other libcs and linux
kernel even) used `uintptr_t`. And GCC didn't check the type
beforehand.
And then HJL changed it to be a type which is the same size and
signedness as `uintptr_t` BUT not exactly the same (on some targets)
and also checking the type at this stage.
HJL didn't update libssp originally. So that broke some x86 targets
including darwin. And then when he changed libssp it still was broken
for i?86-darwin (32bit) because in that case the difference between
`unsigned long` and `unsigned int` which are not compatible at all.
(note systemd also needed a change too).
So we are now in limbo right now where i?86-darwin is broken (and
x86_64-darwin because of multilib).
I think we should revert the original patch which checked the type and
all other band-aids. And start over with a different fix for the
original issue here.
Note our current policy: https://gcc.gnu.org/develop.html#reversion
seems not to take into account this kind of situation. Because even
though there is a "fix", we don't know how many other sources will be
broken or other libc will have to change due to this change. And the
patch to "fix" the issue seems like it is not being reviewed either. I
can't speak for others but I am not comfortable reviewing it.
Plus what was documented on the type before is now different from what
is being checked. Even though it does not seem like it will cause an
ABI incompatibility; it could still end up being an ABI issue.
Thanks,
Andrea
>
>
> --
> H.J.
