[LLVMdev] MCStreamer interface

[Nathan Jeffords]

On Wed, May 5, 2010 at 2:52 PM, Eugene Toder <eltoder at gmail.com> wrote:

> Re having all fragments associated with some symbol -- this makes
> sense if you think in high level terms and assume all symbols to be
> some "objects". All data (fragments) you want to output is associated
> with some "object" (symbol). However, that's probably too high level
> thinking for MC interface. High level objects might not directly
> correspond to object-file level symbols.


I agree with you one this, to me its a question of whose responsibility it
is to determine the mapping, the compiler or the object file format. Another
example would be labels, they are not high level objects in an of
themselves, but must be represented as symbols in current object file
formats.

For example, module level
> inline assembler does not correspond to any symbol, or function may
> have more than one symbol when aliases are used.
>

module level assembly could easily be dealt with as an unnamed symbol that
the object file is free to not create a object-level symbol for (though the
only context I can see a use for this I think it would still be useful to
identity such code).

When you say aliases, I assume you mean embedding object level symbol
records pointing to the same high-level symbol. A high level symbol could
easily report multiple names though its interface.


> Common is not .bss, it's an archaic concept inherited from Fortran. C
> language specifies that global uninitialized variables are put into
> common. This isn't for "programs that forget to use extern" -- you
> can't get the same behaviour with extern, common variables are glued
> together and with "normal" variables, so no object is exclusively owns
> the variable. There's also some subtle difference when linking
> archives.
>

Thanks for the details of this, I will have to update my COFF writer to
properly put these symbols into a COMDAT section, as I currently put them
into .bss section with static linkage.

- Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100505/ef936619/attachment.html>