NodeList DOM bindings break the build with clang

RESOLVED FIXED in mozilla10

Status

()

Core
XPConnect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

Trunk
mozilla10
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Created attachment 565953 [details]
build failure log

The libxul build now fails.  I'm attaching a log to the bug.
Hmm, weird, no idea what's wrong :-/.
I'll try bisecting the range to see if I can find the offending patch...
I could not reproduce this with this mozconfig:

----------------------------
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-libxul

ac_add_options --enable-application=browser
ac_add_options --enable-tests
ac_add_options --enable-trace-malloc
ac_add_options --enable-accessibility

# For NSS symbols
export MOZ_DEBUG_SYMBOLS=1
ac_add_options --enable-debug-symbols="-gdwarf-2"

# Enable parallel compiling
mk_add_options MOZ_MAKE_FLAGS="-j4"

# Needed to enable breakpad in application.ini
export MOZILLA_OFFICIAL=1
---------------------------------

I am building on 10.7, with clang 141650 and mozilla-central 9e090190e01e01c43770642de032f3b6b76c7e4c (the git clone)
Bisecting points to http://hg.mozilla.org/mozilla-central/rev/71625e542826 as the first broken revision.

The interesting thing which happened there is templatizing the NodeList class.  It's possible that clang is not instantiating the templatized functions for some reason.  Using nm to find __ZN3xpc3dom8NodeListI17nsIHTMLCollectionE21getPropertyDescriptorEP9JSContextP8JSObject4jsidbP20JSPropertyDescriptor for example only points to dom_quickstubs.o referencing it, but no .o file is defining it.

I'm currently building with gcc to see which .o file defines it there.
That symbol is defined in dom_quickstubs.o for a gcc build...
So, it seems like explicitly instantiating NodeList<nsINodeList> and NodeList<nsIHTMLCollection> fixes the build by causing clang to instantiate everything correctly.

I don't really know what's causing gcc to instantiate the template and clang not to, but I don't care too much to find out the cause.  What I suspect is that we are only using NodeList's static members in this translation unit, so technically the compiler doesn't need to instantiate the class.

Now, I have to figure out what needs to change on the trunk, because the NodeList class does not exist (at least in that form) any more.
Created attachment 566290 [details] [diff] [review]
Patch (v1)
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #566290 - Flags: review?(peterv)
My patch basically instantiates the templates explicitly instead of relying on the compiler to do it for us.
Attachment #566290 - Flags: review?(peterv) → review+
http://tbpl.mozilla.org/?tree=Try&rev=f0546be1ca70
This has been fixed in recent clangs, I reducing the case to have a log if someone else hits this problem.
https://hg.mozilla.org/integration/mozilla-inbound/rev/01c60492772c
Target Milestone: --- → mozilla10

Comment 12

6 years ago
Try run for f0546be1ca70 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=f0546be1ca70
Results (out of 18 total builds):
    success: 17
    warnings: 1
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-f0546be1ca70
https://hg.mozilla.org/mozilla-central/rev/01c60492772c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
The reduced testcase is

void NewProxyObject(void *);
template<class T> struct NodeList  {
  static NodeList instance;
  NodeList();
  virtual void getPropertyDescriptor();
  static void create();
};
void foobar() {
  NodeList<int>::create();
}
template<class T> NodeList<T>::NodeList() {
}
template<class T> void NodeList<T>::getPropertyDescriptor() {
}
template<class T> void NodeList<T>::create() {
    NewProxyObject(&NodeList<T>::instance);
}
template<class T> NodeList<T> NodeList<T>::instance;

Older versions of clang would not cause a template instantiation and get an undefined reference to getPropertyDescriptor from the vtable (which is used in the constructor, which is used to initialize the static variable).

On the clang side this was http://llvm.org/bugs/show_bug.cgi?id=10020 which got fixed by r132331.
You need to log in before you can comment on or make changes to this bug.