[LLVMdev] MachO and ELF Writers/MachineCodeEmitters arehard-codedinto LLVMTargetMachine

[Aaron Gray]

On Mon, Mar 16, 2009 at 3:26 AM, Aaron Gray <aaronngray.lists at googlemail.com
> wrote:

>  On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray <
> aaronngray.lists at googlemail.com> wrote:
>
>>  I like the idea of a generic MachineCodeWriter, although I prefer the
>>> name 'ObjectFileWriter'...
>>>
>>
>> Thats much more descriptive of the functionality.
>>
>
> Sorry, I disagree actually the MachineCodeEmitter or the
> 'MachineCodeWritter' does not do any file handling at all. Do look at the
> code for the MachineCodeWritter and you will see it only writes to memory
> and if it reaches the end of the allotted memory I believe higher ordered
> logic reallocates a larget buffer and starts again from scratch. This could
> be avoided if they generated fixus for absolute memory references refering
> within the outputted code. Then a alloc function could be called before
> outputting say a 4 byte int and could realloc and copy code and when finally
> written the fixups could be applied.
>
> I am also wondering about the efficiency of std::vector whether we could
> use that for the MachineCodeWriter, or whether we write out own code output
> stream/buffering ?
>
> I still think this is where the crux of the problem lies the upper logic is
> relatively simple compared to this buy looking at what you say it is
> important to get it right.
>


'ObjectCodeEmitter' looks like the right description to parallel the
MachineCodeEmitter. Its emitting object code to a data stream (which is an
object file section) and not direct to a file.

I will knock to gether an ObjectCodeEmitter that is call compatible with the
MachineCodeEmitter and wtites to a std::vector<byte>, so it could replace
the MachineCodeEmitter class generically in usage.

This needs alot of thought and to get things right, and provide the right
incremental patches to get this accepted.

Cheers,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/a3560750/attachment.html>