[Gtk EWS] EWS for Gtk+ should generate the mangled symbols for unresolved symbols

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Vivek Galatage]

It would be great if EWS for Gtk+ generate the mangled version of the unresolved symbols. 

Currently the non-mangled symbols are generated thereby the developer must have gtk+ environment to generate these symbols. But considering cross-platform nature of Webkit, it would be really nice if this information can be generated by the EWS so then the developers can directly use these symbols while exporting it.

[Philippe Normand]

+Gustavo,Martin

Any idea how we can accomplish this? :)

[Martin Robinson]

If we actually know the missing symbols we could run c++filt on the symbol table of the library and then create a map to map backward to the mangled symbol.

[Zan Dobersek]

There's the --no-demangle option that can be passed to the linker to stop the missing symbol being written out in the demangled form.
There's also the COLLECT_NO_DEMANGLE env which has the same effect when set.
http://linux.die.net/man/1/ld

I'll see what the ld and gold linkers support.

[Zan Dobersek]

Setting the COLLECT_NO_DEMANGLE in the environment works with both linkers, so that's what I'd propose doing on the EWS systems.

I also think this would make sense on the buildbots, just so someone can see what symbols need exporting when trying to fix the build.

EWS adjustments should be done by their owners while for the buildbots the variable can be listed somewhere in the buildbot configuration files.

[Philippe Normand]

(In reply to comment #4)
> Setting the COLLECT_NO_DEMANGLE in the environment works with both linkers, so that's what I'd propose doing on the EWS systems.
> 
> I also think this would make sense on the buildbots, just so someone can see what symbols need exporting when trying to fix the build.
> 
> EWS adjustments should be done by their owners while for the buildbots the variable can be listed somewhere in the buildbot configuration files.

I've set that variable on my gtk-wk2-ews. Thanks for investigating this issue!

[Gustavo Noronha (kov)]

Created attachment 199998 [details]
Patch

[Gustavo Noronha (kov)]

How about something like this, so there's one less thing we need to remember when running the queue?

[Zan Dobersek]

Comment on attachment 199998 [details]
Patch

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

> Tools/Scripts/webkitpy/port/gtk.py:46
> +        os.environ['COLLECT_NO_DEMANGLE'] = '1'

Does this properly translate into the EWS's environment?

[Zan Dobersek]

Hrm, the proposed hack ... is a hack. It probably would work for EWSs.

Another solution that I should have pushed for (and I apologize for not doing so) is to pass the --no-demangle flag to the linker. This can be easily done by listing the flag in the AM_LDFLAGS assignment in the root GNUmakefile.am. This way the linker outputs mangled symbols by default, though if someone needs clarification on what the symbol is representing, he can still run the symbol through c++filt.

This would remove the need for exporting the COLLECT_NO_DEMANGLE env on both EWSs and the builders.

Thoughts?

[Gustavo Noronha (kov)]

I like that solution. The mangled symbols are usually more interesting for developers, and anyone who needs it can demangle the symbol very easily, so I think it's OK to add it to the linker arguments.

[Zan Dobersek]

Created attachment 201043 [details]
Test patch

Just a test patch to see how EWSs now behave.

[kov's GTK+ EWS bot]

Comment on attachment 201043 [details]
Test patch

Attachment 201043 [details] did not pass gtk-ews (gtk):
Output: http://webkit-queues.appspot.com/results/436014

[Zan Dobersek]

Success:

./.libs/libWebCoreInternals.a(./.libs/../Source/WebCore/testing/.libs/libWebCoreInternals_la-Internals.o):Internals.cpp:function _ZN7WebCore9Internals23inspectorHighlightRectsEPNS_8DocumentERi: error: undefined reference to '_ZN7WebCore14ClientRectListC1ERKN3WTF6VectorINS_9FloatQuadELm0ENS1_15CrashOnOverflowEEE'
collect2: error: ld returned 1 exit status
make[1]: *** [Programs/DumpRenderTree] Error 1

Closing the bug.

[Zan Dobersek]

Comment on attachment 199998 [details]
Patch

Clearing the r? flag.

[Vivek Galatage]

(In reply to comment #13)
> Success:
> 
> ./.libs/libWebCoreInternals.a(./.libs/../Source/WebCore/testing/.libs/libWebCoreInternals_la-Internals.o):Internals.cpp:function _ZN7WebCore9Internals23inspectorHighlightRectsEPNS_8DocumentERi: error: undefined reference to '_ZN7WebCore14ClientRectListC1ERKN3WTF6VectorINS_9FloatQuadELm0ENS1_15CrashOnOverflowEEE'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Programs/DumpRenderTree] Error 1
> 
> Closing the bug.

Thank you for handling this :) Really appreciated!

[Gustavo Noronha (kov)]

There's a catch! The EWS bots have the environment variable set. I'll take it off so we can get a real test run done, need to ask rego and philln to remove it from theirs too.

[Zan Dobersek]

Yeah, true, didn't cross my mind.

I'll ensure people have the env unset and then retest, IMO it should be just a formality.

[Zan Dobersek]

Created attachment 201624 [details]
Patch

Test #2

[kov's GTK+ EWS bot]

Comment on attachment 201624 [details]
Patch

Attachment 201624 [details] did not pass gtk-ews (gtk):
Output: http://webkit-queues.appspot.com/results/468194

[Zan Dobersek]

All EWSs had the COLLECT_NO_DEMANGLE env removed, and the mangled symbols in the output persist:
./.libs/libWebCoreInternals.a(./.libs/../Source/WebCore/testing/.libs/libWebCoreInternals_la-Internals.o):Internals.cpp:function _ZN7WebCore9Internals23inspectorHighlightRectsEPNS_8DocumentERi: error: undefined reference to '_ZN7WebCore14ClientRectListC1ERKN3WTF6VectorINS_9FloatQuadELm0ENS1_15CrashOnOverflowEEE'
collect2: error: ld returned 1 exit status
make[1]: *** [Programs/DumpRenderTree] Error 1

This now works as expected, closing the bug.

[Gustavo Noronha (kov)]

Looks like we need to do something for this to work on the buildbots as well? Or did we regress?

http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release/builds/39871/steps/compile-webkit/logs/stdio

[Zan Dobersek]

Everything on the builder seems fine (i.e. --no-demangle is present in LDFLAGS), don't really have an idea where this might be failing.

[Zan Dobersek]

Still works on the 64-bit debug builder:
http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Debug%20WK1/builds/3611/steps/compile-webkit/logs/stdio