As @MaskRay pointed out in D63309#1780984, a relocation entry may references a section instead of a symbol entry. This patch adds support for such relocation entries.
Details
Diff Detail
Event Timeline
llvm/test/tools/llvm-objcopy/MachO/copy-relocations.s | ||
---|---|---|
13–17 | I don't think you need this comment. | |
28–31 | I think this should go in place of the comment above. Is it possible to use yaml to create this situation instead of assembly? Assembly is less obvious as to what you want to achieve. | |
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp | ||
209–210 | If you don't change the Sections to unique_ptrs, you could change this to: for (const Section &Sec : LC.Sections) Sections.push_back(&Sec); | |
llvm/tools/llvm-objcopy/MachO/Object.h | ||
93 | Is this really necessary? As far as I can tell, the only place it's actually important is where you create a vector of section pointers, but you can do that without needing these to be unique_ptrs. I've commented above. |
llvm/test/tools/llvm-objcopy/MachO/copy-relocations.s | ||
---|---|---|
28–31 |
That makes sense. AFAIK, yaml2obj does not yet support relocation entries so I'll write a patch for it first. | |
llvm/tools/llvm-objcopy/MachO/Object.h | ||
93 | I think this should be unique pointers. Pointers to vector elements could be invalidated by --add-section/--remove-section operations. |
llvm/tools/llvm-objcopy/MachO/Object.h | ||
---|---|---|
93 | Okay, that's a good point, but why wasn't it an issue already? Assuming that it's actually important, I think moving the unique_ptr changes into a separate patch would make it more obvious what's actually important for this functional change. |
BTW, I noticed that we need a same fix for n_sect field in nlist (in a separate patch).
llvm/tools/llvm-objcopy/MachO/Object.h | ||
---|---|---|
93 |
I think this bug has not been discovered because modifying relocatable objects that enable this feature (r_extern = 0) is a rare case.
Moving unique_ptr changes into a separate parch sounds good to me. I'll submit it. |
llvm/test/tools/llvm-objcopy/MachO/copy-relocations.s | ||
---|---|---|
11 | It prints relocation fields in detail. It looks easier to read to me. $ llvm-objdump --macho --reloc copy-relocs.o copy-relocs.o: Relocation information (__DATA,__bar) 2 entries address pcrel length extern type scattered symbolnum/value 00000000 False quad False SUB False 3 (__DATA,__bar) 00000000 False quad False UNSIGND False 1 (__TEXT,__text) $ llvm-objdump --reloc copy-relocs.o copy-relocs.o: file format Mach-O 64-bit x86-64 RELOCATION RECORDS FOR [__bar]: 0000000000000000 X86_64_RELOC_SUBTRACTOR __text-__bar 0000000000000000 X86_64_RELOC_UNSIGNED __text |
Ping @seiya. We need a separate patch for the for (std::unique_ptr<Section> &Sec : LC.Sections) { changes.
Sorry for being too late. I have no sufficient time to work on this until the end of this month.
I'll take a look at this again later but IIRC, we need to implement relocation entries support in yaml2obj first.
Just in case: I've prepared a diff which adds support for relocations (for MachO) to ObjectYAML / yaml2obj / obj2yaml. I'm planning to send it for code review soon (today or tomorrow).
Thank you for letting me know! I'll update this diff based on yours. I haven't worked on it yet.
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp | ||
---|---|---|
220 | MachO section indices start from 1, not from 0, that's why (i guess) we have <= Section.size() here and -1 below. |
-assemble is the default action. Very few tests specify it. You can just delete it.