[LLD] [COFF] Include "rust_eh_personality" among the known personality functions

[mstorsjo]

Summary

These need to have special treatment wrt to .eh_frame sections
and GC - as long as we don't have a full parser of the .eh_frame
section in the COFF linker.

This fixes Rust unwind issues on i686 mingw as discussed in
https://github.com/msys2/MINGW-packages/issues/9091.

[rnk]

I read the Rust issue. Do you think we should do more to promote relocations to discarded sections into errors on mingw, so that this issue becomes a link error, not a runtime error?

lgtm

[mstorsjo]

In D136879#3889829, @rnk wrote:

I read the Rust issue. Do you think we should do more to promote relocations to discarded sections into errors on mingw, so that this issue becomes a link error, not a runtime error?

Ideally yes, but apparently it's not that easy; we blanket disable the error for mingw due to how GCC handles their non-associative .rdata sections for jump tables: D52600 Also we disable the error entirely for DWARF - since those aren't split up into nice associative sections, so if building with -ffunction-sections and GC, there will be plenty of relocations against discarded things. So offhand I don't really have any good ideas for doing it better, other than going all in for parsing .eh_frame like the ELF linker apparently does - but that's pretty much overkill wrt the effort I had hoped to spend on this issue...

[rnk]

In D136879#3889906, @mstorsjo wrote:

In D136879#3889829, @rnk wrote:

I read the Rust issue. Do you think we should do more to promote relocations to discarded sections into errors on mingw, so that this issue becomes a link error, not a runtime error?

Ideally yes, but apparently it's not that easy; we blanket disable the error for mingw due to how GCC handles their non-associative .rdata sections for jump tables: D52600 Also we disable the error entirely for DWARF - since those aren't split up into nice associative sections, so if building with -ffunction-sections and GC, there will be plenty of relocations against discarded things. So offhand I don't really have any good ideas for doing it better, other than going all in for parsing .eh_frame like the ELF linker apparently does - but that's pretty much overkill wrt the effort I had hoped to spend on this issue...

I guess .eh_frame has relocations to ~all .text sections, so we can't treat it as a GC root either. =/ I guess we'll just live with it.

[mstorsjo]

In D136879#3889916, @rnk wrote:

In D136879#3889906, @mstorsjo wrote:

In D136879#3889829, @rnk wrote:

I read the Rust issue. Do you think we should do more to promote relocations to discarded sections into errors on mingw, so that this issue becomes a link error, not a runtime error?

Ideally yes, but apparently it's not that easy; we blanket disable the error for mingw due to how GCC handles their non-associative .rdata sections for jump tables: D52600 Also we disable the error entirely for DWARF - since those aren't split up into nice associative sections, so if building with -ffunction-sections and GC, there will be plenty of relocations against discarded things. So offhand I don't really have any good ideas for doing it better, other than going all in for parsing .eh_frame like the ELF linker apparently does - but that's pretty much overkill wrt the effort I had hoped to spend on this issue...

I guess .eh_frame has relocations to ~all .text sections, so we can't treat it as a GC root either. =/ I guess we'll just live with it.

Yeah, pretty much.

BTW, the kinda surprising thing here was that we ended up with base relocations for these relocations with a discarded target. Without that, we would just have had a null personality pointer, which would have made the unwind fail differently (probably harder to track down), but a null pointer with a base relocation ends up as non-null, if the image is loaded at a nondefault address. I guess that can lead to some bit of extra overhead, with pointless base relocations in discarded bits in DWARF sections - but probably not worth spending time and effort on either - as it doesn't happen in the PDB/SEH cases.

[mati865]

Thanks, appears to fix unwinding. There are other issues preventing successful compilation but they are seem unrelated.

lld/COFF/Driver.cpp

   if (config->doGC) {
     if (config->mingw) {
       // markLive doesn't traverse .eh_frame, but the personality function is
       // only reached that way. The proper solution would be to parse and
       // traverse the .eh_frame section, like the ELF linker does.
       // For now, just manually try to retain the known possible personality
       // functions. This doesn't bring in more object files, but only marks
       // functions that already have been included to be retained.
-      for (const char *n : {"__gxx_personality_v0", "__gcc_personality_v0"}) {
+      for (const char *n : {"__gxx_personality_v0", "__gcc_personality_v0",
+                            "rust_eh_personality"}) {
         Defined *d = dyn_cast_or_null<Defined>(ctx.symtab.findUnderscore(n));
         if (d && !d->isGCRoot) {
           d->isGCRoot = true;
           config->gcroot.push_back(d);
         }
       }
     }