Bug 146641 – [CMake] Reduce debug info on 32bit using -g1 to avoid OOM

• Component: WebKitGTK
• Status: NEW

[Emanuele Aina]

On a 32bit processors (tested both in a x86 chroot and with the 32bit version of the armhf cross-toolchain for the Raspberry Pi) linking a full debug build results in a out of memory error. Switching to a 64bit build architecture solves the build problem, but it still produce a library that's so big that the dynamic linker on the target system will simply refuse to load with EOVERFLOW (tested with the 64bit version of the armhf cross-toolchain for the Raspberry Pi).

DEBUG_FISSION solves the issue but it's not active by default as it requires the gold linker.

Another option is to severely reduce the amount of debug symbols generated: the -g1 flag will just produce enough symbols to get sensible stack traces, but without any line number info. It's not particularly useful during debug, but for distribution packages it would be an improvement over no symbols at all. :)

[Emanuele Aina]

Created attachment 256216 [details]
Patch

[WebKit Commit Bot]

Attachment 256216 [details] did not pass style-queue:


ERROR: Source/cmake/OptionsCommon.cmake:110:  No space after "("  [whitespace/parentheses] [5]
ERROR: Source/cmake/OptionsCommon.cmake:110:  No space before ")"  [whitespace/parentheses] [5]
ERROR: Source/cmake/OptionsCommon.cmake:111:  No space after "("  [whitespace/parentheses] [5]
ERROR: Source/cmake/OptionsCommon.cmake:111:  No space before ")"  [whitespace/parentheses] [5]
Total errors found: 4 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Csaba Osztrogonác]

Comment on attachment 256216 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=256216&action=review

> ChangeLog:4
> +        [CMake] Reduce debug info on 32bit using -g1 to avoid OOM
> +        https://bugs.webkit.org/show_bug.cgi?id=146641

Just a nit: This line should be same as the title 
of the bug report. Please change one of them.

[Emanuele Aina]

I've attached a patch to override the default -g flag with -g1, while allowing for more specific flags (eg. -ggdb3) to be specified by the user.

This relies of the patch for bug #146640 to work on the armhf toolchain I'm using. Note that here we care about both the build and destination architecture, while bug #146640 was more about the build architecture as the --no-keep-memory does not affects the generated binaries.

Another option would be to properly detect the word size of the destination architecture using CMAKE_SIZEOF_VOID_P instead of CMAKE_HOST_SYSTEM_PROCESSOR.

[Emanuele Aina]

> Just a nit: This line should be same as the title 
> of the bug report. Please change one of them.

Done, thanks! check-webkit-style complains about parentheses, but I guess it's a false positive that can be ignored?

[Emanuele Aina]

Created attachment 257247 [details]
Patch

Rebased on current trunk (r187148) and added a dep from ENABLE(WAYLAND_TARGET) to ENABLE(OPENGL) due to EGL usage.

[Emanuele Aina]

Created attachment 257248 [details]
Patch

Oops, I forgot to add the newline suggested by Zan while I rebased the patch. Added.

[Zan Dobersek]

Comment on attachment 257248 [details]
Patch

Wrong bug, I guess.

[Emanuele Aina]

Created attachment 257250 [details]
Patch

Sigh, I still need to figure out how `webkit-patch` works. The submitted patches were clearly aimed to other bugs, reuploading the original patch.

[WebKit Commit Bot]

Attachment 257250 [details] did not pass style-queue:


ERROR: Source/cmake/OptionsCommon.cmake:111:  No space after "("  [whitespace/parentheses] [5]
ERROR: Source/cmake/OptionsCommon.cmake:111:  No space before ")"  [whitespace/parentheses] [5]
ERROR: Source/cmake/OptionsCommon.cmake:112:  No space after "("  [whitespace/parentheses] [5]
ERROR: Source/cmake/OptionsCommon.cmake:112:  No space before ")"  [whitespace/parentheses] [5]
Total errors found: 4 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Michael Catanzaro]

If you use the -b option to webkit-patch, the patch will always go to the right bug. It's always been detected automatically and correctly when I use 'webkit-patch upload' so I don't bother to pass -b to that, but when using 'webkit-patch post-commits' the patches often go to the wrong bugs unless I pass -b. Bug #143965.