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 <t...@ritter.vg> 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to