(Linux) Why --disable-debug-symbols is not a default compilation flag?

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
bSun0000
Moongazer
Moongazer
Posts: 11
Joined: 2022-03-22, 23:32

(Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by bSun0000 » 2022-05-10, 18:41

Palemoon's default Build instructions includes flags like --enable-strip and --disable-debug but why ac_add_options --disable-debug-symbols is omitted?
Without this flag linker (old ld and "gold" ld) consumes inadequate amount of RAM - more than 3GB even if --no-keep-memory is specified for a linker. Without debug symbols LD barely uses any memory and even work noticeable faster.
What the point of including debug symbols inside obj. files if they are anyway will be stripped of from the final executable file?
Maybe i just don't understand something and this symbols actually do something (in the release build)?

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32200
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: (Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by Moonchild » 2022-05-10, 19:40

As far as I understood the Linux debugging and tracing process, without these symbols it will not, at all, be possible to get a callstack when there's a segmentation fault, and as such it won't be possible to pinpoint e.g. crashes people might run into.
--disable-debug disables extensive in-tree debugging code and compilation that you simply never want in a release version (it's slow as tar).

As for the memory used during compilation, low memory systems are not suited to compile a program of Pale Moon's size and complexity. See "Basic Dependencies" at http://developer.palemoon.org/build/linux/
"You will observe with concern how long a useful truth may be known and exist before it is generally received and practiced on." -- Benjamin Franklin
"Compromise and collaboration lie at the heart of all great endeavours" -- Kassandra
Image

bgstack15
Fanatic
Fanatic
Posts: 118
Joined: 2018-01-22, 23:04

Re: (Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by bgstack15 » 2022-05-21, 20:36

Ah, so the distinction between ac_add_options --disable-debug and ac_add_options --disable-debug-symbols is that disable-debug is on the browser level, and the disable-debug-symbols is about the C function call level?

And as a followup to that question, I still do not understand why you would include the debug symbols if they are still getting stripped at the end. Is it possible that the single binary "palemoon" or "palemoon-bin" has no debug symbols at the end, but its shared libraries still do and that is the important part?

User avatar
The Squash
Apollo supporter
Apollo supporter
Posts: 37
Joined: 2021-03-19, 19:39

Re: (Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by The Squash » 2022-05-23, 02:42

The reason to compile with debug symbols enabled would theoretically be, if the browser ever crashed, the compiler generated debugging symbols when that exact build of the browser was compiled; given those symbols, you could run the browser through a debugger (such as gdb) and potantially see what's going wrong. Since you're a Debian / Devuan user, chances are you've come across packages such as `xxx-dbg` -- example: `pdfcube-dbg`; these are packages separate from the normal packages one might install to get the application, that contain the debugging symbols for the program.

On the other hand, in actual practice, I'm still under the impression that generating all these debugging symbols is a little dubious. On the one hand, when symbols are sripped from the resulting binary files, the debugging symbols still remain in all the thousands of itty-bitty (or not-so-itty-bitty, actually) object files -- the object files which, taken together, are finally linked into libxul and other such resulting libraries. In other words, libxul gets stripped, but the object files used to produce libxul do not get stripped.

On the other hand, having debugging symbols spread out over thousands or tens of thousands of files is not terribly convenient. In the end, one would generally have to re-link libxul anyway -- and not strip it this time around. Changing the `--enable-strip` option in one's mozconfig is nearly certain to cause the Mach build process to regenerate all the required makefiles, and who knows, the resulting object files may not even be the same this time around -- so you'd have to cause the new Pale Moon to crash, and take a dump of that. On top of that, Pale Moon is such a huge program (no offense), that a crash dump with debugging symbols may not even be worth much -- it might be easier to figure out what's wrong some other way.

Do the advantages of debugging symbols outweigh the disadvantages of generating them? I think that's up to the builders of Pale Moon to decide -- unofficial builders included. If you ask me, the answer to the question is a resounding "no". If Pale Moon were built without `--enable-strip`, and then the builder made a copy of the full, unstripped binaries and then stripped the symbols from the other copy, then I think the debug symbols would be quite worthwhile. But as it is, having the build system strip the debugging symbols right after linking, without giving you a chance to preserve any of them, is folly, IMHO. It's especially counterproductive given that the compiler has to put work in to creating the symbols, they take more disk and memory space when linking, and they even slow the build process down by as much as 20% in my tests.

And just to finish off, some people would strongly disagree that taking up more disk and memory space is even a problem. Well, if something provably works plenty well without needing all the oodles of resources that "the build requirements say are needed", then for the user's needs, the "build docs" are telling the user to do something that is literally wasteful. For the main people who build this stuff, they have Zen 3 or similarly beefy build systems, and expect a build to complete in 2-10 minutes. I sympathize with those who build large projects on sub-$3,000, lower-power hardware, or distributed build infrastructures such as OpenSUSE's OBS; for those people, builds can take as long as an hour or more. I build on an Intel Skylake CPU and the builds I produce take over 60 minutes -- and that's without debugging symbols; I used to have build times of 90 minutes or longer, and I still felt lucky. And, those builds are taking up electricity and (ultimately) polluting the planet, or at least raising somebody's electric bill, somewhere.

By now, it's clear that Moore's Law is slowing down -- at a surprisingly quick pace. New, more efficient CPUs aren't going to "solve" the problem forever. I'm not going to tell anyone what to do, but I'd strongly suggest unofficial builders disable debug symbols and save time, money, your patience, and the planet.

And if there's still a reason why the official builds are not done that way, then I'd like to hear it. I may just be convinced.
Hang-Inducing Orphaned Zombie Garbage :twisted:

In theaters now -- Rated R

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32200
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: (Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by Moonchild » 2022-05-23, 07:19

The Squash wrote:
2022-05-23, 02:42
I'm still under the impression that generating all these debugging symbols is a little dubious.
Sorry but there's nothing dubious about including debugging information when object files are created, and contrary to what you're asserting, it is not "more work" to generate and include these in object files pre-linking, since the compiler has to do that work anyway. In fact, many linker optimizations make extensive use of these symbols to create a much better optimized final binary.
The only difference would be taking more disk space on the machine compiling it, from a resource perspective. And if you want to have any hope of debugging an issue with te final binary you want the object files to have symbols in them so you can back-translate addresses to source file locations, even if the final binaries might be stripped. Internal addressing won't change from the stripping process IIUC, so it retains the potential to trace, if you have the object files (similar to having the symbol files on Windows that you can use to back-translate an otherwise stripped and optimized binary to the related source locations; the difference being that symbol files are separately usable without having the object code).
Disabling symbols altogether would make any debugging impossible, period. The minute gain in disk space of the final binaries is not worth the loss of debugging IMHO.

By the way, not stripping binaries on a massive project like Pale Moon will likely be detrimental, and if you want to talk about using too much disk space, well.... ;-)
"You will observe with concern how long a useful truth may be known and exist before it is generally received and practiced on." -- Benjamin Franklin
"Compromise and collaboration lie at the heart of all great endeavours" -- Kassandra
Image

User avatar
The Squash
Apollo supporter
Apollo supporter
Posts: 37
Joined: 2021-03-19, 19:39

Re: (Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by The Squash » 2022-05-23, 23:04

Let's agree to disagree, then. You run the project and build with debugging symbols, officially; I'll continue not generating them in the first place, and if one of my builds crashes (unlikely), that's my problem. Fair enough to me.
Hang-Inducing Orphaned Zombie Garbage :twisted:

In theaters now -- Rated R

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 668
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: (Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by athenian200 » 2022-05-24, 06:22

This discussion is kind of strange to me, because if I were going to complain about the official defaults, I would probably go in the other direction and ask why --enable-strip is a default option. I've definitely encountered a few very early crashes that touch the executable directly and are hard to debug without symbols. Not having them in the object files would be even worse. Granted, it's usually not a big deal if I can reproduce the offending build, but there are times when either the user's machine has a very specific configuration and I can't reproduce the problem, the release was built against a different tag than expected from the version number, etc.

I think what we have is probably the best compromise between the competing concerns of being able to debug people's builds easily and having the build take up too much disk space for some users.
The Squash wrote:
2022-05-23, 02:42
For the main people who build this stuff, they have Zen 3 or similarly beefy build systems, and expect a build to complete in 2-10 minutes. I sympathize with those who build large projects on sub-$3,000, lower-power hardware, or distributed build infrastructures such as OpenSUSE's OBS; for those people, builds can take as long as an hour or more. I build on an Intel Skylake CPU and the builds I produce take over 60 minutes -- and that's without debugging symbols; I used to have build times of 90 minutes or longer, and I still felt lucky. And, those builds are taking up electricity and (ultimately) polluting the planet, or at least raising somebody's electric bill, somewhere.
That isn't actually true. I built (and sometimes still build) on an Ivy Bridge CPU with four cores up until sometime last year, and builds usually took about an hour or less, with full debugging symbols. It's actually not an issue of how new your hardware is, it's about how much RAM you have. The thing is, even though my hardware was ancient, I happen to have 32GB of RAM in it because I didn't expect people to still be building 16GB systems for as long as they have. That's one of the reasons why I was able to run that computer for 10 years. I noticed that on a similar computer with only 8GB of RAM, I saw the kind of behavior you were describing. So it's not so much that you need the newest and most expensive hardware, but you do need a decent amount of RAM, hopefully a few extra cores (I bet even an older Xeon would be fine) and a little bit of patience. ;)

Compiling Firefox on some older computers would sometimes take a whole day, so even two hours is really not a terrible build time for a big application like this. You should see how long it took to compile a Linux kernel an AMD K6-2 back in the day. I actually did the entire SunOS port in a badly-optimized VirtualBox VM where builds could take 5+ hours, and I just did research in between. Maybe this doesn't bother me because I'm used to waiting a whole day on my computer to do certain things like download a big file or compile an application, and just letting it sit while I do something else.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32200
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: (Linux) Why --disable-debug-symbols is not a default compilation flag?

Unread post by Moonchild » 2022-05-24, 08:56

I'm not really sure where long build times and electricity bills/environmental impact come into play in this discussion. We provide binary builds for a reason -- if you build from source instead then that is entirely your choice. And like I said before, I really don't think building with debug symbols is a considerably harder task for the compiler as it needs to do that administration anyway when compiling.

Not using stripping on Linux would result in very large binaries.
The Squash wrote:
2022-05-23, 02:42
For the main people who build this stuff, they have Zen 3 or similarly beefy build systems, and expect a build to complete in 2-10 minutes. I sympathize with those who build large projects on sub-$3,000, lower-power hardware, or distributed build infrastructures such as OpenSUSE's OBS; for those people, builds can take as long as an hour or more.
Beefy build systems still take 20 minutes or so, I think. Not that I'd know, because I'm on an ageing piledriver AMD CPU (FX series). It does take close to an hour to (clobber-)build on that; that is just how big the code base is. For production builds I use one of my in-house servers with a pair of old Xeons in it so i can throw 20 threads at it and have it compile while I do other things on my workstation. Even on that it still takes half an hour.
If you think that's too much, then I hope you'll never try to code-compile Chrome. Multiply everything by a factor 4 or so, including the ram requirements.
"You will observe with concern how long a useful truth may be known and exist before it is generally received and practiced on." -- Benjamin Franklin
"Compromise and collaboration lie at the heart of all great endeavours" -- Kassandra
Image

Post Reply