[PATCH][AsmParser][MC] Allow asm parser to emit elf header flags

[Jack Carter]

If I understand this correctly, There will be a streamer method for both the ascii assembly and object outputs for outputs that affect both.

For command line arguments that affect the eheader output the method will be called during driver (AsmParser/AsmPrinter) constructions.

For directives in the run of processing there will be one or more methods that will called to output the directive with an ascii and object variant for each.

For instance, .abicalls will be generated with OS << "\t.abicalls" for the ascii side and a call to MCA.setELFHeaderEFlags()  on the object side.

Of course we would need to have a method (getELFHeaderFlags()) to get the existing flags since a commandline or inline directive may well override a default value.

There would also need to have a cleanup method as well since ELF flags are not directives and do not necessarily correspond one to one with the directives. Cleanup for the ascii output may entail different operations than the object output.

At all times AsmPrinter and AsmParser will seem to call the same methods without regard to whether the output is ascii assembler or direct object.

Did I get this correct?

Jack
.


________________________________________
From: Rafael Espíndola [rafael.espindola at gmail.com]
Sent: Tuesday, October 15, 2013 9:00 AM
To: Vladimir Medic
Cc: Jack Carter; llvm-commits at cs.uiuc.edu; Jim Grosbach; Rich Fuhler
Subject: Re: [PATCH][AsmParser][MC] Allow asm parser to emit elf header flags

On 15 October 2013 10:53, Vladimir Medic <Vladimir.Medic at imgtec.com> wrote:
> Hi Rafael,
> I have made a small patch that utilizes the methods you defined, and I'd kindly ask you to review it and see if our concept is right. Please note that this is not a complete patch, it's purpose is not to be committed but rather a proof of concept.
> 1. We have changed your emitMipsHackELFFlags method with emitMipsRelocModel which emits a relocation model info to elf header.

This looks like the correct design.

>There is also a helper method emitMipsELFFlags, which in case of AsmStreamer does nothing, and for ElfStreamer actual value is emitted to the output.

This part looks wrong. How would you get the correct flags when using
llvm-mc to parse an assembly file? If these flag differences are from
command line options (instead of assembly directives) then llvm-mc
should implement equivalent options to the gnu assembler ones. They
should then be mapped to flags that are passed to the target object
streamer constructor (like a isMips16 for example).

> The model enumerated values are defined in MipsTargetStreamer. They are meant to be visible from parser since it doesn't need to know which actual output is emitted and should not be aware of elf flags or possible other output values.

OK.
.
> 1. What is the relation between AsmPrinter and TargetStreamer in the lights of these changes? Is AsmPrinter just a kind of streamer or more likely a wrapper that utilizes TargetStreamer? In later case, it seems that some methods currently existing in MipaAsmParser should be moved to MipsAsmTargetStreamer.

The AsmPrinter is just a user of the streamer. It is no different in
that regard than llvm-mc's asm parser.

> 2. As the implementation of TargetStreamer grows, would it make sense to move it to a separate file? Is there any particular reason why you put it in MipsMCTargetDesc.cpp?

Sure. It was just small and convenient to put it in
MipsMCTargetDesc.cpp. It can move to its own file if you want.

Cheers,
Rafael