> I think that one of the goals here is to not make that too dependent on elf.
> For instance, we are in the process of getting rid of all of the dwarf.
> After maddox does that, our only dependence on elf will be as a container
> to hold all of the sections.
> Given that gcc is not always an elf
Cary Coutant wrote:
2) LTO sections need to be able to find "their index" of decls and
types. By "their index" I mean the index that each section used to
reference the decls and types when the section was generated.
Can't you just put an ELF symbol (can be an unnamed local -- could
eve
> 2) LTO sections need to be able to find "their index" of decls and
> types. By "their index" I mean the index that each section used to
> reference the decls and types when the section was generated.
Can't you just put an ELF symbol (can be an unnamed local -- could
even just be a section sy
Arnaud Charlet wrote:
I want to point out that the current implementation of lto is not
compatible with "ln -r", and will need to be modified to support
"cherry picking" the function bodies.
I assume you mean "ld -r", right ?
Arno
yes, of course. Dennis Richie's curse: two letter comm
> I want to point out that the current implementation of lto is not
> compatible with "ln -r", and will need to be modified to support
> "cherry picking" the function bodies.
I assume you mean "ld -r", right ?
Arno
I want to point out that the current implementation of lto is not
compatible with "ln -r", and will need to be modified to support
"cherry picking" the function bodies.
In the current implementation, each lto section (such as what holds
a function body or the streamed information from an ipa pass
