I don't think you need this comment.
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.
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);
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.
That makes sense. AFAIK, yaml2obj does not yet support relocation entries so I'll write a patch for it first.
I think this should be unique pointers. Pointers to vector elements could be invalidated by --add-section/--remove-section operations.
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).
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.
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
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.