[PATCH] D78888: [llvm-objcopy][MachO] Fix symbol table
James Henderson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 28 01:34:52 PDT 2020
jhenderson added a comment.
In D78888#2007119 <https://reviews.llvm.org/D78888#2007119>, @alexshap wrote:
> @jhenderson - as i mentioned above in the summary of the diff (and in the comment as well) (see also https://developer.apple.com/documentation/kernel/nlist_64/1583944-n_type?language=objc) for STABs the value of n_type is interpreted differently, in particular, those bitmasks (N_EXT/N_PEXT) are meaningless (to the best of my knowledge, unless I'm missing smth).
Yeah, I got that bit, sorry for not being clear. The reason I'm asking about it is because the `isExternalSymbol()` code checks that it is not a STAB and has N_EXT. That means we have a logical matrix of 4 code paths in this function: "not STAB, not N_EXT", "STAB, not N_EXT", "not STAB, N_EXT" and "STAB, N_EXT". It's possible due to the usage of the function (I haven't looked heavily at it), that the last of these (the one that isn't tested) can't actually be exercised. Of course, C++ lazy evaluation means that in its current state, only the STAB part is tested when it is a STAB, but it would be just as correct to rewrite the code as `return n_type & MachO::N_EXT && !isSTAB();`, so we should test that case (assuming we can get into this code at all in that situation).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D78888/new/
https://reviews.llvm.org/D78888
More information about the llvm-commits
mailing list