On Tue, May 26, 2026 at 6:12 PM H.J. Lu <[email protected]> wrote: > > On Wed, May 27, 2026 at 9:05 AM Andrew Pinski <[email protected]> wrote: > > > > > > > > On Tue, May 26, 2026, 5:59 PM H.J. Lu <[email protected]> wrote: > >> > >> 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. > > > > > > Yes our policy on reverting makes a mention of that issue: > > Note that no distinction is made between patches which are themselves buggy > > and patches that expose latent bugs elsewhere in the compiler. > > > > Are we going to address the ssp mess in GCC 17?
Can you write up a RFC on what needs to be done and that will influence what changes and where are to be done? Because right now it is not obvious what are all of the problems and if the mess is inside GCC or libc (and more). It might make sense to also invoke LLVM now because there are now ABI implications and from what I can tell LLVM libc follows glibc. Thanks, Andrea > > > > > > >> > >> > 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. > > > > -- > H.J.
