Closed
Bug 331827
Opened 18 years ago
Closed 18 years ago
illegal instruction executed on mac os x86
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: rginda, Assigned: mark)
Details
Attachments
(5 files)
4.23 KB,
text/plain
|
Details | |
193.63 KB,
text/plain
|
Details | |
513 bytes,
patch
|
Details | Diff | Splinter Review | |
5.41 KB,
patch
|
jaas
:
review+
mark
:
superreview+
|
Details | Diff | Splinter Review |
3.75 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
There doesn't seem to be a bugzilla component for xpcom/xptcall any more, so I guess maybe this could be classified as a build config issue. Either way, I'll try to find an owner on IRC tomorrow. A custom build on a mac os x86 MacbookPro exits after XPCOM registration when it attempts to execute an illegal instruction. I imagine this is a problem with xptcall build goop. Build log an stack trace on the way.
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
Reporter | ||
Comment 3•18 years ago
|
||
Other notes: I'm building this with the gtk2 toolkit, using a small patch from darwin-ports. I'll attach the patch. XP_MACOSX is *not* defined by this configuration. Maybe XP_UNIX is supposed to be enough, I'm not really sure. I tried hand-hacking a "#define XP_MACOSX" into the xptcinvoke_unixish_x86.cpp. That moved the illegal instruction elsewhere.
Reporter | ||
Comment 4•18 years ago
|
||
this is the patch from darwin-ports to teach mozilla how to build for x11 on darwin.
Reporter | ||
Updated•18 years ago
|
Assignee: nobody → mark
Assignee | ||
Comment 5•18 years ago
|
||
The xpconnect component's in core. At the very least, we'll also need to pick up the OS X code in xptcstubs_unixish_x86.cpp too. I'll take a look at this tonight.
Component: Build Config → XPConnect
Product: Firefox → Core
Version: unspecified → Trunk
Comment 6•18 years ago
|
||
Is your OS_ARCH Darwin? That should be enough to define XP_MACOSX unless I'm missing something. I think we should be defining XP_MACOSX here.
Reporter | ||
Comment 7•18 years ago
|
||
Yeah, my OS_ARCH is darwin. I'm not sure why XP_MACOSX isn't getting defined. I put a debug statement in the configure around line 5382, and it triggered. For some reason, HOST_CFLAGS isn't being respected. Probably a good thing for me, since it includes -DNO_X11, and I *want* x11. If I hack a "#define XP_MACOSX" into mozila-config.h my build fails, but I forgot to save the error message. If I hack a "#define XP_MACOSX" into xptcprivate.h, things *seem* to work. Mozilla starts and I seem to be able to use it normally.
Assignee | ||
Comment 8•18 years ago
|
||
XP_MACOSX is NOT defined unless you're using a Mac-specific widget toolkit. I thought it was too. I was wrong: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=1.1636&mark=4044,4089#4038 We should look at changing this behavior to define XP_MACOSX whenever you're targeting a Mac (as Benjamin and I thought we were doing), and using widget ifdefs to control widget implementations. XP_MACOSX is defined in HOST_CFLAGS for Darwin build hosts, but HOST_CFLAGS is only used to build host programs.
Assignee | ||
Comment 9•18 years ago
|
||
This makes xptcstubs consistent with xptcinvoke about using KEEP_STACK_16_BYTE_ALIGNED instead of using the XP_MACOSX platform check. It also moves the platform check from the header into the Makefile, where it's possible to check $(OS_ARCH). The other changes in xptcstubs are because I had a lot of trouble with the three separate asm blocks, especially when the stack pointer was being left in a random non-ABI-conforming state between the second and third block. The compiler doesn't recognize when you tell it that you've trashed the stack pointer, and I'm afraid that a future optimizing compiler might try to do something in between blocks and fail. I already made a similar change in xptcinvoke.
Attachment #216488 -
Flags: review?(joshmoz)
Assignee | ||
Comment 10•18 years ago
|
||
This patch fixes the broken things in a gtk2/darwin nonstatic build: nsMacUtils (universal binary check) should not be present because we don't link against CoreFoundation. cairo should bring in freetype includes as OS_INCLUDES and not LOCAL_INCLUDES, so that they come AFTER the Moz includes. (I was getting the system-installed libpixman headers which were out of date and wouldn't work with the in-tree Cairo.) libxul should be named libxul.dylib and not XUL. When Mac widgets are not selected, Firefox looks for libxul.dylib, the XULRunner packager does not attempt to do Mac packaging, and nsXPCOMPrivate.h does not look for XUL.framework. libbrowsercomps should link against glib when the nsGNOMEShellService is built. (This is the bug solved by the DarwinPorts patch.)
Attachment #216489 -
Flags: review?(benjamin)
Comment 11•18 years ago
|
||
Comment on attachment 216488 [details] [diff] [review] Make xptcall align the stack for all $(OS_ARCH) == "Darwin" looks good
Attachment #216488 -
Flags: review?(joshmoz) → review+
Assignee | ||
Updated•18 years ago
|
Attachment #216488 -
Flags: superreview?(shaver)
Assignee | ||
Comment 12•18 years ago
|
||
Comment on attachment 216489 [details] [diff] [review] Provisional build patch Fx static builds in at least some configurations are still broken because the final binary is not linked with -lXft.
Assignee | ||
Comment 13•18 years ago
|
||
Comment on attachment 216488 [details] [diff] [review] Make xptcall align the stack for all $(OS_ARCH) == "Darwin" shaver sez: sr=shaver
Attachment #216488 -
Flags: superreview?(shaver) → superreview+
Comment 14•18 years ago
|
||
Comment on attachment 216489 [details] [diff] [review] Provisional build patch I'm not sure I understand why mac+gtk2 shouldn't build macutils and whatnot, but I don't mind what you've got here if you've got a long-term plan brewing.
Attachment #216489 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 15•18 years ago
|
||
Both patches have been checked in on the trunk. It would have been pointless to build nsMacUtils and bring in CoreFoundation just for it when the only consumers of nsMacUtils are in #ifdef XP_MACOSX. For the short term, I just wanted to get the gtk2/Darwin build back in shape. As things stand now, it doesn't think it's XP_MACOSX, it thinks it's pure XP_UNIX, with no Mac-isms at all. Some of the Mac-isms like nsMacUtils should arguably be part of a gtk2/Darwin build, but that really requires going through a bunch of ifdefs and deciding what belongs where. That's a possible long-term direction, but it'll have to happen elsewhere, unless there's enough community resistance and they want the gtk2/Darwin build to remain XP_UNIX only. That might actually be best, to allow support for people running Darwin without OS X on top, but to allow primary development on that build to be conducted on Darwin + OS X. Either way, it's like a tier-7 platform.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•