[PATCH] D123435: [lld-macho] Initial support for EH Frames

[David Spickett via Phabricator via llvm-commits]

DavidSpickett added inline comments.


================
Comment at: lld/test/MachO/eh-frame.s:57
+# CHECK:   Second level indices:
+# CHECK:     Second level index[0]:
+# CHECK:       [0]: function offset=0x[[#%.8x,F - BASE]],              encoding[{{.*}}]=0x52{{.*}}
----------------
DavidSpickett wrote:
> DavidSpickett wrote:
> > Hi! This is very late report but as you'll see I don't think your patch is wrong, perhaps llvm-objdump is doing strange things.
> > 
> > This test is failing on our 32 bit armv8 bot: https://lab.llvm.org/buildbot/#/builders/178/builds/2463
> > 
> > When I run the first objdump command from my AArch64 build I get:
> > ```
> > <       [0]: function offset=0x00000508, encoding[1]=0x52010000
> > <       [1]: function offset=0x0000050c, encoding[0]=0x00000000
> > <       [2]: function offset=0x00000510, encoding[3]=0x14000020
> > <       [3]: function offset=0x00000514, encoding[2]=0x24000068
> > <       [4]: function offset=0x00000518, encoding[0]=0x00000000
> > ```
> > When I do the same from a 32 bit Arm build I get:
> > ```
> > >       [0]: function offset=0x00000508, encoding=0x52010000
> > >       [1]: function offset=0x0000050c, encoding=0x00000000
> > >       [2]: function offset=0x00000510, encoding=0x14000020
> > >       [3]: function offset=0x00000514, encoding=0x24000068
> > >       [4]: function offset=0x00000518, encoding=0x00000000
> > ```
> > 
> > The missing `[ ]` after encoding is what causes lit to fail to match.
> > 
> > Now it looks to me like the `[0]` after encoding is actually a bug on 64 bit but I'm totally guessing here. Just going by the seemingly random order of the numbering.
> > 
> > Do you have any idea if those are actually expected to be there?
> (I see the same `[ ]` checked for in `lld/test/MachO/compact-unwind-stack-ind.s`, in the same `Second level index[0]` section)
As usual as soon as I write it out I see what it means. The number is the encoding number that's why the two 0x0..0 are labelled with [0]. I see there are 2 functions over in objdump one for compressed (which has these []) and regular, I'll investigate those for any 32 bit strangeness.

So your patch is fine sorry for the noise!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123435/new/

https://reviews.llvm.org/D123435