I am not enjoying new GCC's insistence on tail calls

It upsets the pid provider

Maybe it's compiling tail calls differently than older versions? my vague recollection was that there were significant chunks of the kernel network stack that critically depended on tail call optimizations in the sun C compiler. As in, you'd blow out the kernel stack if you made a change that prevented one of these calls from being compiled as a tail call.

[illumos-gate] 16790 /usr/lib/pci/pcidb could intuit which tables to search -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16859 October 2024 hwdata update -- Robert Mustacchi <rm⊙fo>

sommerfeld: I'm actually trying to trace various out-of-gate usermode stuff

Half of the functions I was trying to trace today have an :entry but no :return probe etc

So you look at the text and, ah yes, I guess you do end with "jmp"

on other hand, I was cleaning some third party bits for smartos + gcc 14... and it was just as awful as I did remember from the end of 90's so, it is good to see nothing has really changed:P

the hedge does not trim itself I suppose!

the problem, of course, has 2 sides -- one is that those maintainers and developers will need to perform cleanups, but also, in some cases we are using older versions and I do not think anyone outside will touch them any more:)

so its gradual upgrades and also growing bloat...

yeh, I'm going to be delaying gcc 14 for as long as possible

makes sense, yep.

jclulow: I believe I believe you want to give it -fno-optimize-sibling-calls or something spelled very like that

jclulow: basically look at everything toomas, andy, and myself have added to Makefile.uts and Makefile.master to stop it being a bastard, and then reproduce

I added an option to 4.x, that I'm not sure is still necessary, that makes it follow the i386 ABI even when it feels i doesn' need to, also

you're going to want that, because the upshot of the option is that if function A calls function B, and function B has no other visibility, it might not inline B (because size, whatever), but instead emit both A and B with "more efficient" prologue/epilogue

jclulow: they had told us in the past that if we care that much about debugging, we want to be using -Og which might also help you

(I seem to recall it not doing enough, but it presumably does some)

richlowe: tah

That all sounds plausible. I suspect we should be building more software in omnios-extra, etc, that way

[illumos-gate] 16863 implement C23 stdbit.h -- Robert Mustacchi <rm⊙fo>