On Tue, May 26, 2026, 6:20 PM H.J. Lu <[email protected]> wrote: > On Wed, May 27, 2026 at 9:11 AM 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? > > I opened: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125466
Can you write to glibc asking if they are willing to fix their definition or we are going to allow both definitions? I think you need buy in from a few places if we are going to fix this. > > > > -- > H.J. >
