Invalid xdata blocks reported by dumpbin

[ZacWalk]

This is the function entry that seems to be corrupt:

0:000> .fnent 0000000140016590

Debugger function entry 000001ed`6837db30 for:

[/home/roriddle/src/mingw-woarm64-build/build-aarch64-w64-mingw32/gcc/aarch64-w64-mingw32/libstdc++-v3/libsupc++/../../../../../code/gcc-master/libstdc++-v3/libsupc++/eh_alloc.cc @ 456] (00000001`40016590) testthrow!_GLOBALsub_IZN9gnu_cxx9freeresEv

Exact matches:

testthrow!_GLOBAL__sub_I__ZN9__gnu_cxx9__freeresEv (void)

Start=testthrow!_GLOBALsub_IZN9gnu_cxx9freeresEv (0000000140016590) Xdata=testthrow+0x1e2e0 (000000014001e2e0)

  [RawPdata=00016590 0001E2E0]

FuncLen=23C Vers=0 X=1 E=0 Epilogs=1 CodeWords=1

Prolog unwind:

  00: CA0A.... +0000 stp   x27,x28,[sp,#0x50] ; Actual=stp   fp,lr,[sp,#-0xA0]!

               +0004 (end sequence)

Epilog #1 unwind: (Offset=CA Index=19)

Exception Handler=00000002`23e306c9

[RawXdata=0850008F 04C00065 88C90ACA E3E306C9]`

I am working to try to arrive at a vacuumized repro for this to debug.

[movediedi]

@ZacWalk: I think this is a regression with your logic to shift the .xdata header left by 2 bits. When we have functions containing 8 or greater code words, the most significant bits fall on the floor and are never restored. I may leave this fix for you, since you are intimately familiar with that code in gcc.

[ZacWalk]

Thanks Ron. The relocation might need to be replaced by a new relocation type that I would need to implement. The shift trick was designed to reuse existing relocation code in Binutils. I will take a look when I get time.

[movediedi]

@ZacWalk: Here is the .s file that repros: eh_alloc.zip