Closed
Bug 945879
Opened 11 years ago
Closed 10 years ago
Produce crash report symbols for darwin-on-linux builds
Categories
(Infrastructure & Operations Graveyard :: CIDuty, task, P3)
Infrastructure & Operations Graveyard
CIDuty
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: hwine, Assigned: hwine)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
The "buildsymbols" step does not currently run on linux for at least two reasons:
- the current process uses mac binaries that do not run under ma-loader
- the breakpad tools are not set up for cross compilation (bug 543111)
For initial deploy, we'll transfer the data to a mac for these steps.
Comment 1•11 years ago
|
||
Specifically, we'll likely need to do the following:
1) Copy the entire object directory (or at least every .o file and every binary that gets linked) from the builder to a Mac machine, using the exact same directory structure.
2) Run the equivalent of "make buildsymbols" on the Mac, but pointing at a (pre-built?) dump_syms binary.
3) Run the equivalent of "make uploadsymbols" on the Mac to put the symbols on the symbol server.
4) Additionally upload the symbol package next to the app package on FTP.
Comment 2•11 years ago
|
||
This is to support the "build on linux, dump symbols on mac" case, which is what I thought this bug was about, but maybe I'm wrong?
Assignee | ||
Comment 3•11 years ago
|
||
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2)
> This is to support the "build on linux, dump symbols on mac" case, which is
> what I thought this bug was about, but maybe I'm wrong?
You are correct -- thanks for the detailed steps in comment 1
Comment 4•11 years ago
|
||
This is my WIP patch to make dump_syms compile under Linux. There's a few symbols that would need to be fixed/added to make the whole thing link.
As you can see, it involves some dodgy modifications to things. You also need a /usr/include from a Mac for some mach-o headers and the like. I'm not planning on working on this further unless we decide that we really do want to do as much stuff on Linux as possible.
Updated•11 years ago
|
Assignee: nobody → hwine
Priority: -- → P3
Comment 5•10 years ago
|
||
This doesn't appear to be going anywhere. :(
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Comment 6•10 years ago
|
||
Did we decide that the work in comment 1 was too unwieldy? In the interim I also ran into a description of how dsymutil works:
http://stackoverflow.com/questions/10044697/where-how-does-apples-gcc-store-dwarf-inside-an-executable/12827463#12827463
Comment 7•10 years ago
|
||
I never got a sense of whether we wanted to copy objdirs all over to Linux, or whether we wanted to do all the processing on the Linux side...
Assignee | ||
Comment 8•10 years ago
|
||
Summarizing as I understand it. Both prior approaches (fix linux side processing vs copy all obj to a mac) take significant implementation time. Factoring that cost in, it appears less expensive to continue to operate mac hardware builders.
If anything changes to make one approach or the other "easy peesy", we would revisit.
Comment 9•9 years ago
|
||
bug 543111 fixed this the right way, by making `buildsymbols` work fine on a Linux host.
No longer blocks: 927061
Updated•7 years ago
|
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Updated•5 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•