Closed Bug 491774 Opened 15 years ago Closed 14 years ago

crashreporter fails to compile when doing 32-bit cross compile on Mac OS X 10.6 seed 10A335

Categories

(Toolkit :: Crash Reporting, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: jaas, Assigned: jimb)

References

Details

Attachments

(6 files)

The crash reporter fails to compile when doing a 32-bit cross-compile on Mac OS X 10.6, where 64-bit is the default arch. Use the attached mozconfig and Mozilla trunk code to reproduce on Mac OS X 10.6 seed 10A335 (or later).

(No, I am not using a PDP-11!)
Also, need this filed upstream, since we don't take local patches. Happy to sync with upstream if we get it fixed there, though.
Attached file build failure output
Ok, so it looks like we just need another block here that sets CPU_TYPE_X86_64:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/mac/macho_walker.cc#63

Can you patch that and submit it upstream?
Attached patch partial fix v1.0Splinter Review
Its not really that easy, breakpad lacks 64-bit support in general for darwin so doing that isn't enough. Here is a patch that does it though because I have a question - what is the right alternative to __i386__ to use for x86-64? __LP64__ will also be true for 64-bit PPC.
Attached file 64-bit build errors
defined(__x86_64__)
(In reply to comment #4)
> Created an attachment (id=376468) [details]
> partial fix v1.0
> 
> Its not really that easy, breakpad lacks 64-bit support in general for darwin
> so doing that isn't enough.

Should be ok, though, since we disable breakpad support on 64-bit systems in configure. Only dump_syms (and its bits) need to compile, since we compile those for the host architecture, but they only need to deal with x86 binaries.
blocking2.0: --- → ?
I wouldn't block on this. You can always --disable-crashreporter.
blocking2.0: ? → -
Josh, this is fixed now, right?
yes
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I'm hitting this with the latest mozilla-central, with 10.6 and Xcode 3.2.1, and a universal build setup -- I think this got regressed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Breakpad's Macintosh symbol dumper uses deprecated functions for
dealing with mixed-endianness code. This patch provides an overloaded
function, ByteSwap, that automatically chooses the CFSwap* functions
from <CoreFoundation/CFByteOrder.h> appropriate for its argument's
size.
Since we're using its types, #include <stdint.h>.

Don't cast 'void *' to 'uint32_t' where we need to do byte-pointer
arithmetic. Instead, use 'char *'; the language guarantees that
sizeof(char) == 1.

To make the above easier, pass pointers to byte buffers as 'char *', not
'void *.

Use natural pointer arithmetic where possible. If ptr is a 'struct A *', then
write:
        (struct B *) (ptr + 1)
instead of:
        (struct B *) ((char *) ptr + sizeof(struct A))
This helps us avoid (say) using the size of the 32-bit Mach-O header to
skip a 64-bit Mach-O header. (The latter has an extra 32-bit word at the
end.)
With those two patches, I can get dump_syms to build for x86_64.  I don't think it runs, though.
Assignee: nobody → jim
The patch series up at the URL below fixes the symbol dumper on Mac.  It works fine compiled as either 32-bit or 64-bit code.
The URL:
http://hg.mozilla.org/users/jblandy_mozilla.com/breakpad-mq/file/8e6f6dd0b0d6

We'll be importing this into the tree as soon as it gets reviewed upstream.
Verified that all unit tests build and pass on Mac x86_64.
Fixed by the update in bug 567424.
Status: REOPENED → RESOLVED
Closed: 15 years ago14 years ago
Depends on: 567424
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: