[llvm-commits] [PATCH] Object File Library

[Michael Spencer]

On Mon, Nov 15, 2010 at 8:46 AM, Jason Kim <jasonwkim at google.com> wrote:
> I am curious as to  how these patches will impact the existing
> MCObjectWriter code. What is the overall intent beyond llvm-nm and
> llvm-objdump?
>
> Thanks
>
> -jason

My main goal is to write a portable linker, loader and binary
tool-chain with extensive bitcode support. In doing so I plan to make
the components modular enough to support the needs of any other tools
that need them.

I'm not sure if it makes sense to make MCObjectWriter fully format
independent due to the different semantics of the different formats.
It would also require a major change to the code generators to handle
GOT/PLT. However, there's no reason it can't use the object
serialization API for the individual formats.

- Michael Spencer

> On Sun, Nov 14, 2010 at 5:20 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
>> 2010/11/14 Rafael Espíndola <rafael.espindola at gmail.com>:
>>>> I have no problem with that. The only thing I don't like about them
>>>> currently is the super typedef macro I had to add to avoid adding 14
>>>> lines of typedefs in each templated class :(.
>>>
>>> Can you declare a base class with just those typedefs? You could then use
>>>
>>> class foo : public ElfTypeDefs<target_endianness, is64bits>
>>
>> That's what I originally was trying to do. The problem is that you
>> have to explicitly bring the typedefs into scope because of some weird
>> C++ template rule.
>>
>>>> Oh, and I haven't decided how to add writing to
>>>> packed_endian_specific_integral yet. Currently it's not possible
>>>> (without reinterpret_cast).
>>>
>>> np. Whatever the solution is (even explicit method calls) is something
>>> that can be shared.
>>>
>>>> - Michael Spencer
>>>>
>>>
>>> Cheers,
>>> Rafael
>>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>