I’m a little bit stuck in code reading right now. Maybe some of you can help me to understand fast if what I need is feasible or not.
I was trying to understand if currently asm parser in llvm allows to easily extract from an asm file variable names alongside with their values and their addresses.
Thanks for the help!
You need to extract it from the source? Is it possible to use the resulting object file instead?
Note that there’s no way to get an ‘address’ but you can get a section offset. The section offset for both code and data are available in the object file and from the assembler as it writes the object file.
The contents of the assembly file - instructions and directives - contribute to the resulting layout. The AsmParser can find tokens and build instructions but shouldn’t know how it will get layed out.
Hi Brian, thanks for your reply.
My goal is to be able to extract from an assembly file (i.e. source compiled to assembly, directly) the static global vars declared in the source. So far I haven’t found any API in the llvm asm parser to serve my purpose. Do you know if/ how I can accomplish that?
I don’t quite know exactly, but I suppose one way would be to modify ELFWriter::writeSymbol() to emit something when a symbol appears that matches your criteria. I’m taking some liberty here assuming you can use an ELF object file. I imagine there’s something similar for macho/coff.
Then again, that information is present in the object file too. You could use llvm-readelf or obj2yaml to extract what you want.
Maybe you could give a little more context about how you plan to use the info and the community could offer a better answer.
I’ll try to give you more context through an example.
What I need is to extract the value of a variable (aka a label) inside an assembly file; for example given the following assembly (compiled with armv7-a clang 10.0.0):
Well, one good way to get this is to let the assembler make the object file and dump the contents of the object file. I’ve illustrated w/objdump disassembly but a more robust way might be to use the location and read the data directly from the object file. See below for an example w/objdump.
But if you can’t make the object file for some reason, I think ELFWriter might have what you need, or at least be a starting point. There is no arch-independent / object-file-independent way to determine where “myvar” will end up. So the way I think it makes sense to get this information is to wait until it’s being emitted into the object file. But this is so late in assembly that it doesn’t seem to make as much sense to modify the assembler so much as you might want to dissect its output. And there’s lots of great tools and libraries for dissecting object files.
However, another approach might be to modify the assembler to look for labels matching “myvar” and set some kind of mode that lets you accumulate the subsequent “.word” directives.
Also: you described “myvar” as being a variable in a C program. So this is compiler-emitted assembly? Maybe it makes more sense to intercept this value in the compiler instead of in the assembler. It might not be very robust to try and scoop up .word’s - this output could vary and still be legitimate compiler output.
Even if that would be a straightforward and good way to proceed, I cannot take the way you proposed with objdump as the files I’ll be dealing with are .s only, no obj files at all.
So far, I’ve been able to intercept tha emission of the Label and Value while parsing; in particular, this has been done through the override of the virtual void MCStreamer::emitValueImpl(const MCExpr *Value, unsigned Size, SMLoc Loc = SMLoc()) method.
For what I’ve been able to read from the doxygen documentation, MCExpr should have an attribute of MCSymbol * type which points to the symbol it refers to (in this way it should be easy to match the “myvar” label). Unfortunately I can’t find a way to extract the actual value from it (i.e. .long directives followed by the values, as shown in the asm file in the last reply).
Now, is it possible to extract the value the way I’ve just described? If yes, how?
I’m open to other suggestions and ways to achieve this, anyway (if any).
I suspect that the MCSymbol for ‘myvar’ simply represents a position in the output stream, and certainly it is not directly tied to whatever instructions or data directives might chance to follow it. You’re capturing the labels and data directives as they’re emitted, but you’ll have to make the association between them yourself. The assembler does not consider ‘myvar’ to be a variable name; it’s the name of an offset within a section, which is (ultimately) an address in the final object. How it gets used semantically by the program is not the assembler’s concern.
Yes, like Paul says: the label you’re looking for doesn’t have a value as far as the assembler knows. But you could modify the assembler to set some kind of state when it encounters the label you’re interested in, and you can check that state when handling directives like
…sorry to beat a dead horse but the assembler can take the “.s” input and make the “.obj” file. If you’re willing to modify the assembler, why not use it as-is? It’s designed to do the transformation you want. If you use the assembler as a library, you can even emit the object file into memory and dissect it there.
Then again, you could modify the assembler to provide another streamer that only overrides the emit() methods you care about - covering the label and directives.