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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Oct 15 20:06:23 PDT 2013


On 15 October 2013 18:54, Jack Carter <Jack.Carter at imgtec.com> wrote:
> If I understand this correctly, There will be a streamer method for both the ascii assembly and object outputs for outputs that affect both.

A more precise way to put it is from
http://llvm.org/docs/CodeGenerator.html#the-mcstreamer-api:
"MCStreamer has one method per directive".

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

They should not be methods in the streamer interface. They don't
change the printed assembly (since they are command lines for the
assembler instead), so they can be options for the object streamer.

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

Not sure what you men by "in the run of processing".

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

Assuming those are the semantics you want, it looks like a reasonable
way to implement a EmitABICalls in the asm and obj streamers
respectively.


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

If you have diretives that set a bit in the elf flags, the object
streamer is the place to keep track of that. It can talk with the
assembler if needed too.

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

Not sure what you mean by cleanup method.

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

Yes, that is the fundamental design why we have MC in the first place.

> Did I get this correct?
>
> Jack

Cheers,
Rafael



More information about the llvm-commits mailing list