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

Nick Kledzik kledzik at apple.com
Mon Aug 26 15:56:31 PDT 2013


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!

-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





More information about the llvm-commits mailing list