[llvm-commits] [PATCH] Object File Library

[Michael Spencer]

On Fri, Nov 12, 2010 at 9:17 PM, Nick Kledzik <kledzik at apple.com> wrote:
> Michael,
>
> This ObjectFile interface has a very simple model of object files as a sequence of symbols and sections.  How are you thinking of doing Normalization?  Will it be layered on top of this interface, or an orthogonal interface?

Normalization will be layered on top.

> If on top, then this interface will need to be much richer.  If orthogonal, then perhaps this interface should not be named "ObjectFile", but "SimpleObjectFile" or "RawObjectFile".  Something so that "ObjectFile" can we used as the normalized interface.

I agree that it will need to be richer, however, I'm only adding
things to this interface when they are required. I want to keep it as
simple as possible, but no simpler.

There are lots of things currently missing, a major one being all the
crazy flags and attributes, and there are things that should be at a
higher level, like isSectionText (which I hacked in for llvm-objdump).

> Since in the current world the platform nm tool and file format are paired, what model should we follow for llvm-nm?  Should it display the output like the current OS for any object file format?  Or should the output of nm reflect the file being parsed and not the OS you are on?    Here is a simple file and compiled  on Darwin and FreeBSD and the output of the platform nm tool:
>
> [snip...]
>
> Conceptually these files contain the same simple C code, but we can already see the platforms and file formats have diverged on symbol names (prefix), extra symbols (unwind info), values, etc.
>
> -Nick

llvm-nm should display exactly what's in the object file, and should
match the system nm output for the main system file format. Prefixes,
extra symbols, and etc are not part of the file format.

The Serialization layer's purpose is to abstract out the differences
between the file formats binary representation, not what they actually
contain. The Normalization layer is tasked with handling that.

I guess it's time I write some documentation :P.

- Michael Spencer

>
>> From: Michael Spencer <bigcheesegs at gmail.com>
>> Date: November 11, 2010 6:23:34 PM PST
>> To: llvm-commits <llvm-commits at cs.uiuc.edu>
>> Subject: [llvm-commits] [PATCH] Object File Library
>>
>> 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
> <object-S0P0-add-LLVMObject.patch><object-S0P1-add-COFF-support.patch><object-S0P2-add-ELF-support.patch><object-S0P3-llvm-nm.patch><object-S0P4-llvm-objdump.patch><object-S0P5-add-tests.patch>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>