Fedora Decides After All To Allow Default Compiler Flag To Help Debugging/Profiling

[chocolate]

Sounds like a "not my problem" thing. The last 12 inches laptops with respectable build quality, serviceable internals, OK keyboard, hot-swap external batteries, as well as a flat front that doesn't cut into your wrists, are the Lenovo ThinkPad X270 and the Panasonic CF-MX5 and they sport 7th gen and 6gth Intel low voltage CPUs respectively. It's not really "old" hardware my any means, but wow Fedora Workstation is unusable on them; Silverblue, even more so. I suppose choices like this one add up over the years. One less useful OS choice to be considered respectable when on the go and introducing a foreign computer inside clients dealing with classified stuff (then again, they expect you to use a company laptop but uuhhhhh Windows, and also it's typically less hardened than mine, and also of course you'll be doing other stuff when out and about, or at home, or at the cafe, and having one common base removes some cognitive overhead).
I've been experimenting with MicroOS and it's better, but default GNOME forty-whatever still stutters like crazy as soon as the "Activities" overview has more than zero windows inside. I guess I'll keep testing MicroOS but starting from a minimal installation and adding some kind of wlroots-based environment on top.

Distrobox renders any argument about development environments moot anyway. The most convenient environment is either Ubuntu because there's already the needed documentation for it, or Arch in case of stuff you have to wing by yourself, because there you don't have to worry about separate header packages. So it's not like Fedora Silverblue added anything of real value even though I can say it's fairly problem-free if your hardware can mask the (perceived?) "bloat" underneath.

Thanks in advance to those who will be helping upstream developers profile stuff.

[MadCatX]

Nope. MSVC does not allow you to omit frame pointers.

MSVC in x64 does not give you the control over frame pointer omission but it can and will omit it it it decides that it's safe to do.

[carewolf]

Nope. MSVC does not allow you to omit frame pointers.



It's part of SEH on Windows for x86_64.

No... You can't even turn it on, but it is mostly omitted anyway. Besides release builds on Windows are completely useless, and can not even give you a backtrace, while on Linux with existing defaults of no frame pointers a useful backtrace is always generated, and you only need debug symbols for line numbers and variable dumps.

But keep in mind different architectures. The frame-pointer is not always safe to drop, it depends on the arch if it is needed or not, and whether it is needed in leaf-function calls, etc.

[Weasel]

Nope. MSVC does not allow you to omit frame pointers.

Because it's ON by default. And you can't force it to generate them. Sounds like Microsoft should've taken over Fedora...

See: https://stackoverflow.com/questions/...64-vc-compiler

The ABI does not require frame pointer. Show relevant passage if you believe otherwise.

It's part of SEH on Windows for x86_64.

Except it's not. Quote where it says it is.

The fact you got likes without a single proof shows how cringe this community truly is, trying to spread their bullshit beliefs.

[mdedetrich]

No... You can't even turn it on, but it is mostly omitted anyway. Besides release builds on Windows are completely useless, and can not even give you a backtrace, while on Linux with existing defaults of no frame pointers a useful backtrace is always generated, and you only need debug symbols for line numbers and variable dumps. calls, etc.

Well obviously if someone releases software on Windows that omits the frame pointer its not very useful, but thats precisely what is being talked about. At least when it comes to Microsoft's own software, when appropriate they do leave in frame pointers and they even did research on it (see https://www.microsoft.com/en-us/rese...176&type=exact). At least for releasing software on Windows, its been recommended for a while to include frame pointers, and for msvc the default is to leave in frame pointers, you have to explicitly disable it (see https://learn.microsoft.com/en-us/cp...?view=msvc-170). For x64 you don't even have control over this, the frame pointers will be there unless its completely safe to remove it.

[old486whizz]

So I have to chime in here after seeing this lunacy of re-voting for something thrown out and rejected only to have it accepted a few weeks later with no real difference to the request.

Let's see - first off this is the wrong way to do things.
Opt-OUT of a profiling / developer setting?
This should be Opt-IN if anything (eg - a specific project needs to gather info from all those using it while they develop it).
The weird niche case that might happen to smaller / 'third-party' projects (I'm thinking maybe Playstation 4 emulation or something), but I can't think of anything that might go into mainline Fedora to validate this - not even Gnome.

Secondly, let's see the two major use cases for Fedora (and then the last smaller use case), and why this option is absolutely wrong in all cases, then I'll get to the argument of "our tooling should work":
UC1) Ordinary users
Ordinary users want their programs to essentially run, and run performantly/proficiently. You know what they don't use? Developer tools and profiling tools in order to send that information back to the developers.
If a user is willing to fill out a bug report and willing to run profiling tools - you know what else they're willing to do? Install a profiling build of the packages in question.
I use KDE - not Gnome - and this tool seems to be mostly Gnome based... Why is this a distro-wide, opt-out setting that affects packages for which different tools are suited?

Conclusion: this setting will not help in this scenario.. Ordinary users will not run the tooling - only developers will.

UC2) Servers / 'production' environments (desktops)
While rare, companies may have servers and laptops running Fedora... A bit silly IMO since you should be paying the big boys like Ubuntu / Redhat / SUSE / ... and actually getting proper support where you contact them and actually have technical experts respond and do things like custom/debug builds especially for you when you have issues.
But, like I say, it does happen sometimes.
For servers in a production environment - number 1 you should be replicating data back into a test environment (normally called a production support environment) to replicate issues, generally you have test environments and pre-production environments for testing too, as well as development of in-house code etc.. But let's say that you don't want to go through the hassle of replicating + obfuscating data from one environment to the other like you actually should do, and instead want to profile in production. .... Well then, there are these things called source RPMs, which give you the source + compilation flags etc, and you can customise the compiler flags and - get this - install an RPM with profiling turned on!
Does this mean you have to maintain + build your own RPMs? ... Sure... But that's what you pay your employees to do to allow them to do specific profiling on specific production builds because you're crazy enough to want to do that.
If it's for a specific bug - and again I point to paying Redhat for support - then specific packages will be provided to enable specific debugging flags to allow debugging / profiling.
In this case, profiling might actually make a contribution to upstream if the company reports it back properly.
For desktops (I can only think remote technicians here), then 90% of "profiling" goes out the window. No-one cares about a technician's laptop performance in companies. If anything they try to hinder it with lockdown software, with security software, etc.. But let's say a technician supporting infrastructure does see a performance issue so bad they are impacted - again installing a profiling package / set of packages isn't such a big thing. This would probably be seen by many users supporting the company and so the company would push for this to be fixed / worked around. So profiling packages being installed would be trivial.
In this case, profiling might actually make a contribution to upstream if the company reports it back properly.

Conclusion: this setting may help in this scenario, if the company reports the issues back up properly on their specific issues - but the global / distro-wide compile flag is not required.


Let's see the last (and only valid) use-case this setting helps out with:
UC2) Developers
Developers use this flag to debug/profile the application. It seems like it's useful for certain tools. I have no objection to developers using this compiler flag.
HOWEVER, a developer will be developing. They will be compiling stuff anyway - so why aren't they using their builds to enable the developer flag in the project they are actively working on?
Developers are generally working on code that is ahead of the distro release code - but let's say that is not the case, and the code being worked on is in-line with that from the distro, and certain code are from linked libraries from elsewhere and that has a knock-on effect to the code being worked on (going against the blog post that mentioned things being more statically linked nowadays) then why don't you use source RPMs and again "build your packages with the profiling flag enabled" ?
Basically, developers are probably already doing this type of thing already - so all you're doing is punishing the performance of overall running, for the fact developers need to do specific things to develop their code.
Conclusion: this setting is useful / needed for developers... But developers aren't the biggest usecase and should be using different development procedures to enable the tooling usage

Almost lastly, the "I want my tooling to work" argument is really a "the developer wants the tooling to work in their developer build".
Which - yes it should work in your developer build.
Why are you trying to get the developer tool working in non-developer environments where it will never (or close to never) run?

Lastly - all those use-cases kind of point to "why are you enabling a profiling setting rather than installing a profiling RPM when that need arises which is very niche".
And you know what would actually be the proper way to do this? It would be "modules" or a "-profile" build of the packages build specifically for this use-case (if the "source"+build process is too annoying for you).
Why not have a specific profiling build/module that people could use to install and gather profiling?
You have that for versions - why not profiling/debugging too?
If someone is willing to help you out by gathering profiling/debugging, then them installing that specific code is a non-issue for them.
If the developer is running tests, or wants their system to have the profiling packages - then again it's available to them.

This all comes down to (as was said by someone before me) who the target is.
The target isn't the developers - it's the users. Users don't often (or close to zero) contribute anything other than "it's slow" or "it's not working" (and they generally move on to try other things or go back to what was going on previously).
Those that are willing to contribute back up, are generally willing to install packages to gather the extra information required, run the extra flags required to dump, are willing to run profilers etc... Again, the target of the distro isn't for this small sub-group.

--
old486whizz