[llvm-commits] Extract MachObjectWriter class to own header and code files

[Daniel Dunbar]

On Fri, Mar 19, 2010 at 6:23 PM, Aaron Gray
<aaronngray.lists at googlemail.com> wrote:
> On 19 March 2010 10:55, Daniel Dunbar <daniel at zuster.org> wrote:
>>
>> On Tue, Mar 16, 2010 at 8:37 AM, Aaron Gray
>> <aaronngray.lists at googlemail.com> wrote:
>> > On 16 March 2010 15:20, Daniel Dunbar <daniel at zuster.org> wrote:
>> >>
>> >> On Mon, Mar 15, 2010 at 6:01 PM, Aaron Gray
>> >> <aaronngray.lists at googlemail.com> wrote:
>> >> > On 16 March 2010 00:31, Daniel Dunbar <daniel at zuster.org> wrote:
>> >> >>
>> >> >> Hi Aaron,
>> >> >>
>> >> >> This has been on my list, but for the time being I find it
>> >> >> convenient
>> >> >> to have all the code in the same place. I also want to factor out a
>> >> >> few more minor things before splitting in the target independent
>> >> >> assembler and the object file writer.
>> >> >>
>> >> >> Is this blocking work you are hoping to do?
>> >> >
>> >> > Hi Daniel,
>> >> > It would be good to get to the stage where I can work on the
>> >> > COFFWriter
>> >> > and
>> >> > COFFStreamer.
>> >>
>> >> Ok. Do you mind waiting ~a week?
>> >>
>> >> > Basically I can wait but I thought a few file and class wise
>> >> > normalizations
>> >> > would not go a miss :)
>> >> > Also I wanted to introduce a common ObjectWriter abstract class for
>> >> > MachObjectWriter, ELFObjectWriter, and COFFWriter, with Write and
>> >> > virtual
>> >> > WriteObject methods.
>> >>
>> >> Right. I have this stuff planned out in my head, along similar lines.
>> >> I'll try to get it in the next week but right now I wanted to get
>> >> x86_64 Mach-O support up, which gives two concrete implementations to
>> >> factor for. Work for you?
>> >
>> > Okay, thats great :)
>>
>> As of r98955, MCAssembler is now Mach-O independent.
>>
>> We still need to either change MCMachOStreamer to be MCObjectStreamer,
>> or implement MC{ELF,COFF}Streamer classes, before immediate work on
>> ELF/COFF MCObjectWriters can begin.
>
> Nice, thanks Daniel that was quick ! The only thing I am not sure about is
> the genericity of the Layout code when its applied to COFF and ELF. The
> section headers/table is very simple on COFF.

My expectation is that the generic layout code should always be
"correct", and ideally support optimal layout -- these things are tied
to the target not the object file format so it should be able to be
generic. Any sane object file format should be able to encode any
(sane) executable sequence, so I expect it will be enough to produce a
working assembler.

What it might not end up being enough for is to produce an assembler
which creates .o files that are identical to the system assembler.
During bringup this is important for finding bugs, and if need be we
can always add more target hooks, similar to the ones used by the
Darwin implementation, to try and match glitches in the system
assembler.

 - Daniel

> Anyway I will implement COFF file generation and see what happens. I have my
> own COFF file reading and dumping code which may come in hand as it will
> work across platforms with out needing binutils'es objdump across platforms.
> With a COFFWriter., ArchiveReader, and PEWriter too I am looking to
> implement a COFF Linker for LLVM.
> I have to modify MCSectionCOFF, TLOF and AsmPrinter to get rid of legacy
> implementation.
> But before that I will be semi preocupied as llvm-gcc 2.7 prerelease-1 and
> main line SVN llvm-gcc-2.7 are broken on Cygwin with a weird syntax error
> that, causes error propogation from stddef.h threw the Windows.h headers.
> Its weird as MinGW compiles properly. Anyway got to get to the bottom of
> this first. Hopefully this should only take a few days.
> Many thanks,
> Aaron
>