search for: machinecodeemittersarehard

Displaying 4 results from an estimated 4 matches for "machinecodeemittersarehard".

2009 Mar 16
0
[LLVMdev] MachO and ELF Writers/MachineCodeEmittersarehard-codedinto LLVMTargetMachine
Aaron, I mailed in the same mail twice (by mistake), you answered both copies. Differently! In any case, I've re-read what exists. I'm dumping what I understand here, so that we can discuss in detail. I'm using MachO as the example object format, as the ELF code is totally broken and outdated. Lets use the following as the basis for our discussion? There are 3 classes which
2009 Mar 16
0
[LLVMdev] MachO and ELFWriters/MachineCodeEmittersarehard-codedinto LLVMTargetMachine
> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big
2009 Mar 16
2
[LLVMdev] MachO and ELF Writers/MachineCodeEmittersarehard-codedinto LLVMTargetMachine
>> 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.
2009 Mar 16
2
[LLVMdev] MachO and ELFWriters/MachineCodeEmittersarehard-codedinto LLVMTargetMachine
> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?