Table-driven QI breaks NS_GET_IID from XPCOM static glue on Mac OS X

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
12 years ago
8 years ago

People

(Reporter: andrew, Unassigned)

Tracking

({platform})

Trunk
x86
Mac OS X
platform
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
Attempting to link an XPCOM component on Mac OS X (x86, 10.4, gcc 4.0.1) gives the following error:
g++  -DXP_UNIX -DXP_MACOSX -DNO_X11 -fpascal-strings -no-cpp-precomp -fno-common -Wall -ggdb -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fno-rtti -D__darwin__ -DXP_DARWIN   -o pcenvStage/components/libDataCollector.dylib DataCollector.o DCModule.o CellMLToRDFTree.o MathMLInputServices.o TextRepScanner.o TextRepParse.tab.o -L. -L/Users/cmiss/Build/omniORB-4.0.7/lib -L/Users/cmiss/physiome_builds/trees/XPCORBA -L/Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/lib -L/Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/bin -l'xpcom' -l'nspr4' -l'plc4' -l'omniORB4' -l'omnithread' -l'xpcomglue_s' -l'xpcorba' -bundle -Wl,-executable_path,/Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/bin
/usr/bin/ld: /Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/lib/libxpcomglue_s.a(nsCOMArray.o) malformed object, illegal reference for -dynamic code (reference to a coalesced section (__TEXT,__const_coal) from section (__TEXT,__text) relocation entry (3))
/usr/bin/ld: /Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/lib/libxpcomglue_s.a(nsCOMArray.o) malformed object, illegal reference for -dynamic code (reference to a coalesced section (__TEXT,__const_coal) from section (__TEXT,__text) relocation entry (7))

Looking into the relocation table with otool -rv shows that relocation entry 3 (offsets start at 0) in glue/nsCOMArray.o is...
000003be False long   n/a    SECTDIF True      0x000003f8
         False long   n/a    PAIR    True      0x00000344
and entry 7 is...
00000353 False long   n/a    SECTDIF True      0x000003f8
         False long   n/a    PAIR    True      0x00000344

Disassembling nsCOMArray.o with otool -tv, and looking for addresses 3be and 353, respectively, gives...
000003bc        leal    __ZN11nsISupports11COMTypeInfoIiE4kIIDE-0x344(%ebx),%ecx
(which is in function __ZNK15nsCOMArray_base13IndexOfObjectEP11nsISupports, i.e. _ZNK15nsCOMArray_base13IndexOfObjectEP11nsISupports)
and...
00000351        leal    __ZN11nsISupports11COMTypeInfoIiE4kIIDE-0x344(%ebx),%ecx

Note: __ZN11nsISupports11COMTypeInfoIiE4kIIDE demangles as nsISupports::COMTypeInfo<int>::kIID

What seems to be happening here is that nsISupports::COMTypeInfo<int>::kIID is a constant inside a template, and so is in a coalesced constant section. However, it seems that the ld on OS X won't link static libraries (like the XPCOM glue) into shared libraries, if it means that the dynamic library has to reference a coalesced section.
(Reporter)

Comment 1

12 years ago
Created attachment 246647 [details] [diff] [review]
Make kIID visible

Removing the NS_HIDDEN from kIID fixes this issue. This is because gcc4 on OSX will not coalesce template across dynamic libraries if visibility is hidden:
From http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/
"If you want to ensure that a template instantiation in a dylib is not merged with template instantiations in any other dylib, use the visibility attribute to give the template hidden visibility."

It also doesn't make sense to hide something like kIID when we explicitly want everyone to share it.
Attachment #246647 - Flags: review?(benjamin)

Comment 2

12 years ago
We do not want everyone to share it and we do explicitly want frozen-linkage code to use your own copy.

I'm not sure what a coalesced section means. On ELF systems, we want the reference to kIID to be made as a direct call, and not made through the PLT.

Updated

12 years ago
Attachment #246647 - Flags: review?(benjamin) → review-

Comment 3

12 years ago
I think keeping it hidden is the right thing to do. My suspicion is that the .a needs to be built differently, but not sure how - even after nearly seven years at Apple, there's a bunch of this I still don't grok. We do want coalescing between .a's and within a dylib, so the release note is not entirely relevant.
(Reporter)

Comment 4

11 years ago
I think this should be blocking 1.9 because C++ XPCOM components are very important to the extensibility and Mozilla-as-a-platform stories and as far as I can tell this will make them unusable on Mac OS X.
Flags: blocking1.9?
Keywords: platform

Comment 5

11 years ago
Firefox itself uses frozen linkage for components such as browsercomps, so this is not a general problem but somehow specific to your situation.
(Reporter)

Comment 6

11 years ago
I think that I am using frozen linkage here (certainly it compiles without having to define anything like MOZILLA_INTERNAL_API).

It looks like this results from using -lxpcomglue_s together with -bundle, which I believe is the normal way to make frozen linkage XPCOM components).
We compile our components with -lxpcomglue_s and -bundle and have never seen this problem.

Here's a typical link line for us:

gcc -o sbLibraryManager.dylib -lpthread -lobjc -shared-libgcc -lstdc++ -Wl,-executable_path,../../../../../compiled/dist/Songbird.app/Contents/Frameworks/XUL.framework -bundle -L../../../../../dependencies/macosx-i686/mozilla/debug/lib sbLibraryManager.o sbMediaListViewMap.o sbLibraryManagerModule.o  -lplds4 -lnspr4 -lxpcom -lxpcomglue_s

Updated

11 years ago
Flags: blocking1.9? → blocking1.9-

Comment 8

8 years ago
This bug is dead, since it's obviously working in general.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.