[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:
> 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)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123435