[lld] r211921 - [mach-o] refactor x86_64 relocation handling.

[Tim Northover]

Hi Nick,

I'll try to come up with a suitable name and uncomment those debug lines.

>>> +    MachODefinedAtom *inAtom = file.findAtomCoveringAddress(section,
>>> +                                                            reloc.offset,
>>> +                                                            &offsetInAtom);
>>> +    if (!inAtom)
>>> +      return make_dynamic_error_code(Twine("no atom at r_address"));
>>
>> Isn't this more of an assertion-failure error? It seems like a gappy
>> section shouldn't even be able to exist in an ill-formed MachO file.
> It means a malformed mach-o file.  For instance, the sect index in a
> relocation is wrong.  I try to turn all malformed file issues into errors,
> and leave asserts for programming errors in the linker itself (not
> programming errors in the tool that generated the bad .o file).

I agree on keeping .o problems as errors, but wouldn't this case be
covered by the previous test? "reloc.offset > section.content.size()"?

If that's false, then how could we end up without an atom at any given
address unless the linker *has* gone wrong? I could see it happening
with a segment reference, but that's not how symbols work, from what
I've read so far.

Cheers.

Tim.