More info: removing -g dwarf2 from the flags seems to have resolved both types of bad sections.
The build is here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3b5af6123e2677f616c33786beb1ec812431f763&selectedJob=173414445 However, relocating the debug symbols (as described in https://stackoverflow.com/a/866731) causes objcopy to segfault. It seems all x64 MinGW builds I have tried doing this to cause objcopy to segfault. I filed a bug on this here: https://sourceware.org/bugzilla/show_bug.cgi?id=23061 -tom On 13 April 2018 at 02:39, Tom Ritter <[email protected]> wrote: > Okay, I've been digging into this and have more information. I have a > few things I'm going to try, but any insight into what might be > happening or why or other things to try would be greatly appreciated. > > The DWARF data is definitely bad. Specifically the offset into the > .debug_abbrev section is wrong. > https://ritter.vg/misc/stuff/dwarf-error.html shows the details. > > I did more more analysis into the bad sections here: > https://ritter.vg/misc/stuff/dwarf-error-2.html > > The bad sections fall into two categories: > 1) Stuff in Firefox we produce with yasm. I don't know why this is, > but I think it's coming from > https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/frontend/context.py#375 > so I'm going to try and just remove debug information for this stuff > > 2) Stuff from mingw-w64, specifically mingw-w64-crt and winpthreads. > I have no idea why these files are producing DWARF version 2 debugging > information or why the offsets are corrupted. > > -tom ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
