[llvm-commits] [PATCH] Object File Library
Michael Spencer
bigcheesegs at gmail.com
Mon Nov 22 17:00:13 PST 2010
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
More information about the llvm-commits
mailing list