llvm dev - May 2012 - [LLVMdev] New binary formats just for LLVM?

Hi,

I was thinking about the potential for link-time optimizations.  And the
fact that you already now output LLVM bitcode to object files, archives,
and perhaps even executables (that would give a .NET flavor to LLVM, I
wonder if this can be made to work seamlessly on Windows [1]).  Then I
thought about the fact that you seem intent on supporting all native
formats that you run into.

I was then thinking something along this path: "What if we were to create a
new set of binary formats just for LLVM, that people can use if they prefer
clang(++)?"

It is probably me that is something wrong with, but I have a strong dislike
for the existing object, archive, and executable formats.  For one, most of
them are designed in such a way that you'd think there was something
mentally wrong with the guys who designed them.  Look at COFF strings, for
instance, and notice how complicated it is to decode a COFF string when all
you ought to do was to look up an offset into a string table.  And so on
with the various formats.

What do you nowadays with LLVM extensions?  Do you encode them in the
bitcode that you output to object files or what.  I'm thinking of all the
information that usually gets lots when you output an ordinary object file:
pretty much all but the binary image and a set public symbols and
relocations.

My angle to LLVM is this: LLVM is the future, GCC is the past.  Not all may
agree with me, but I think we'll see GCC fade away as clang/clang++ become
more widely used.  So why accept the limitations of GCC object file formats?

I am not trying to start a flame war or anything.  I can be told to shut up
if I produce too many stupid questions in too short a time :-)

[1] It can.  Simply reserve a specific extension, such as "lbc" (LLVM
BitCode), to the file type and then define a system-wide association to the
bitcode interpreter, and you're all set.


Cheers,
Mikael
-- The Day You Stop Wondering Is the Day You Died.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120528/3b835b9a/attachment.html>

On 5/28/2012 9:13 AM, Mikael Lyngvig wrote:
> What do you nowadays with LLVM extensions?  Do you encode them in the 
> bitcode that you output to object files or what.  I'm thinking of all 
> the information that usually gets lots when you output an ordinary 
> object file: pretty much all but the binary image and a set public 
> symbols and relocations.
>
> My angle to LLVM is this: LLVM is the future, GCC is the past.  Not 
> all may agree with me, but I think we'll see GCC fade away as 
> clang/clang++ become more widely used.  So why accept the limitations 
> of GCC object file formats?
Because they're not GCC's object file formats, they're (according to
Wikipedia at least) a development of System V ABI. You also have the 
issue that there is an important subset of programs that rely on the 
format of the executables: defining your own file format for an 
executable breaks shared library loading on Unix-based systems without 
modifying the appropriate version of libc. You might be able to pull it 
off if you can give strong reasons why this new format is better, but 
"gcc is dead" isn't a very good reason.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor