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

someguy just.s0m3.guy+llvmdev at gmail.com
Sun Mar 15 23:49:54 PDT 2009


> 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.

IIRC the memory allocation is done in the MachineCodeEmitter, not the
higher level (see startFunction and finishFunction). The current
implementation has startFunction allocate some (arbitrary) reserve
size in the output vector, and if we the emitter runs out of space,
finishFunction returns a failure, causing the whole process to occur
again. This is icky.

It would be far better if the underlying buffer would grow
automatically (with an allocation method in the base class, as you
suggested), as code is emitted to it.

> '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 can live with that. Before you implement anything, can we try and
define the responsibilities of the various classes?

We have MachineCodeEmitter, which is responsible for actually emitting
bytes into a buffer for a function. Should it have methods for
emitting instructions/operands, or should it only work at the byte,
dword, etc. level?

ObjectCodeEmitter,  is responsible for emission of object 'files' into
a memory buffer. This includes handling of all object headers,
management of sections/segments, symbol and string tables and
relocations. The ObjectCodeEmitter should delegate all actual 'data
emission' to the MachineCodeEmitter.

ObjectCodeEmitter is a MachineFunctionPass. It does 'object wide'
setup in doInitialization and finalizes the object in doFinalize(?).
Each MachineFunction is emitted through the runOnFunction method,
which passes the MachineFunction to the MachineCodeEmitter. The
MachineCodeEmitter calls back to the ObjectCodeEmitter in order to
look up sections/segments, add globals to an unresolved globals list
etc.

I'm not too happy about the broken encapsulation here. I'd prefer to
find a better way to model this.



More information about the llvm-dev mailing list