[llvm-commits] [PATCH] Object File Library

[Daniel Dunbar]

I have no comments on the patches because I am too self centered to
want to review them on vacation. :)

However, I am going to be pushing in a bunch of libObject related
stuff soonish, so it would be great if the stuff could land in TOT so
that I can tie my stuff together with it.

Even if you want review on some of the specific pieces, I would like
it if you pushed in at least the stub structure for things like
llvm-objdump so I can hang stuff on to them.

 - Daniel

On Mon, Nov 22, 2010 at 5:00 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
> On Thu, Nov 11, 2010 at 9:23 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
>> Attached are updated patches to be reviewed. I've split them up into
>> the generic API, the COFF and ELF implementations, tool changes, and
>> tests.
>>
>> This does not currently implement the Serialization/Normalization
>> split that I reference in my talk. I'm going to wait to do that split
>> until the line is firmly defined, as I still haven't figured out how
>> exactly to represent relocation data.
>>
>> A current major blocker that you can see throughout the ELF
>> implementation (and ignored in COFF (which I knew much better and
>> didn't need debugging help)) is how invalid object file errors are
>> handled. I currently just call report_fatal_error, which is really not
>> how they should be handled. I've been complaining about the same
>> problem in the System library on IRC recently too while trying to
>> clean up the Windows impl.
>>
>> What I would like to do is use an error object based on the concept of
>> std::error_code to report both system (IO, memory, syscall), and
>> "parsing" errors from invalid object files. This should also include
>> at least the address in the file at which the error occurred. I don't
>> feel that we need detailed (clang style :P) diagnostics because tools
>> generate object files, not people. At the same time I don't want to
>> just dump "object file invalid at 0xdeadbeef" to the user. Using
>> 'std::error_category' would allow mixing the two while proving more
>> detailed info such as "invalid symbol name string index at
>> 0xblahblah". Also, each object file could use a custom error_category
>> for special errors. It also allows clients that simply don't care to
>> just check for success and not pay for message formatting.
>>
>> - Michael Spencer
>>
>
> Pinging reviews on the rest of the patches (all but the first).
>
> - Michael Spencer
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>