On Wed, May 27, 2026 at 8:39 AM Andrew Pinski <[email protected]> wrote: > > 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.
This mess has been there for a very long time. My patch just exposes it. Requires ssp in libc should resolve most issues. > 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. -- H.J.
