[llvm-commits] [PATCH] Object File Library

[Michael Spencer]

On Sat, Dec 18, 2010 at 4:55 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Dec 15, 2010, at 6:48 PM, Michael Spencer wrote:
>
>> On Mon, Nov 22, 2010 at 8: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
>>>
>>
>> Ping.
>
> Hi Michael,
>
> Can you resend the latest version of the patches?
>
> -Chris

Attached.

- Michael Spencer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Object-Add-ELF-support.patch
Type: application/octet-stream
Size: 30577 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101218/c0919c32/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-llvm-nm-Update-to-use-the-new-LLVMObject-library.patch
Type: application/octet-stream
Size: 11550 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101218/c0919c32/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Add-llvm-objdump.patch
Type: application/octet-stream
Size: 11754 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101218/c0919c32/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Object-Add-some-tests.patch
Type: application/octet-stream
Size: 10851 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101218/c0919c32/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Object-Add-COFF-Support.patch
Type: application/octet-stream
Size: 13026 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101218/c0919c32/attachment-0004.obj>