[PATCH] Support native mach-o names in MachOFormat.h

[Charles Davis]

On Aug 26, 2013, at 4:56 PM, Nick Kledzik wrote:

> 
> On Aug 26, 2013, at 3:08 PM, Charles Davis <cdavis5x at gmail.com> wrote:
> 
>> 
>> On Aug 26, 2013, at 3:27 PM, Nick Kledzik wrote:
>> 
>>> Chip,
>>> 
>>> I talked to Michael Spencer and Jim Grosbach off-list and they both think switching Support/MachO.h to use the documented mach-o names is a good idea.   You said you’ve been sitting on the patch a while.  What has been holding you back from getting the patch in?
>> There were some patches ahead of it in my local Git tree, which makes it difficult to use git svn dcommit on it (at least, until I realized I could just put it and patch #2 into a separate branch and commit from that).
>>> I’d like it to go in, to help me with my lld work.
>> Would you like me to commit them now?
> Assuming everything still builds and passes the unit tests, then yes.  Thanks!
r189314. Thanks!

Chip

> 
> -Nick
> 
> 
>>> 
>>> On Aug 19, 2013, at 3:54 PM, Charles Davis <cdavis5x at gmail.com> wrote:
>>>> On Aug 19, 2013, at 4:22 PM, Nick Kledzik wrote:
>>>> 
>>>>> Wow, that was fast Charles!
>>>> Yeah, I've been sitting on those patches for a while.
>>>>> 
>>>>> I did not know that Support/MachO.h even existed!
>>>> Outside of LLDB, hardly anyone does. They added it, and AFAIK they're the only ones that use it right now. (These patches will obviously change that.)
>>>>> Why does Object/MachOFormat.h and it both define the same things differently?
>>>> I don't know, and that's why I wanted to get rid of one. I suspect that whoever added Object/MachOFormat.h probably didn't know about Support/MachO.h either.
>>>>> There was some recent changes to ELF headers to layer them.  Is there something analogous we need to do for mach-o?
>>>> We used to do something similar--we had the MachOObject class that does about the same thing as the ELFFile class (i.e. it was a low-level interface to a Mach Object), except without the heavy template meta-programming. MachOObjectFile was then just a thin wrapper around it, just as ELFObjectFile is now just a wrapper around ELFFile. But Rafael Espíndola got rid of that a while back, saying something about the InMemoryStruct template not working right. (He also wanted to add the kind of template meta-programming to Mach-O that ELF was using for its structs, but that got shot down.)
>>>> 
>>>> Chip
>>>> 
>>>>> 
>>>>> -Nick
>>>>> 
>>>>> On Aug 19, 2013, at 3:14 PM, Charles Davis <cdavis5x at gmail.com> wrote:
>>>>>> On Aug 19, 2013, at 4:02 PM, Eric Christopher wrote:
>>>>>> 
>>>>>>> Probably wouldn't take much to fix up all the name uses and leave out
>>>>>>> the conditional?
>>>>>> I have two patches; one does what Nick's patch does, but to <llvm/Support/MachO.h>, and also updates everything using it in LLVM to use the new names, and one that strips out the now-redundant <llvm/Object/MachOFormat.h> header and changes everything using *that* to use the new names.
>>>>>> 
>>>>>> Chip
>>>>>> <0001-Support-MachO-Add-a-bunch-of-defines.patch><0002-Move-everything-depending-on-Object-MachOFormat.h-ov.patch>
>>>>>> 
>>>>>>> 
>>>>>>> -eric
>>>>>>> 
>>>>>>> On Mon, Aug 19, 2013 at 2:57 PM, Nick Kledzik <kledzik at apple.com> wrote:
>>>>>>>> [+patch]
>>>>>>>> 
>>>>>>>> include/llvm/Object/MachOFormat.h is odd in that it makes up new names for the public mach-o format structs and constants (e.g. it defines LCT_Segment instead of LC_SEGMENT). LLVM does not handle ELF this way.  LLVM defines SHT_PROGBITS just like the standard ELF header (although llvm puts them into a namespace).  This current set up makes it hard to reconcile the public mach-o documentation with llvm source code.
>>>>>>>> 
>>>>>>>> This patch adds all the standard mach-o names for structs and constants in the llvm::object::mach_o namespace.  All the existing names remain, but I put them inside #ifndef LLVM_NO_OLD_MACH_O_NAMES, so that if someone wanted to switch to the standard names they could define LLVM_NO_OLD_MACH_O_NAMES, do a full build, and update whatever failures are seen.
>>>>>>>> 
>>>>>>>> This issue came up during a code review of lld, as to why lld was defining it own mach-o constants instead of using the ones in llvm.
>>>>>>>> 
>>>>>>>> -Nick
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> llvm-commits mailing list
>>>>>>>> llvm-commits at cs.uiuc.edu
>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> llvm-commits mailing list
>>>>>>> llvm-commits at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>