recognise DW_AT_SUN_amd64_parmdump dwarf attribute

sun created this tag for identifying functions that dumped their
register arguments onto the stack.

this is enough for llvm-dwarfdump to recognise and print the attribute.

hopefully someone will commit it.

cheers,
dlg

Index: include/llvm/Support/Dwarf.def

This’ll need a test case, in any case.

Adrian/Paul: Pondering this, any thoughts on how conflicts in the vendor extension range of attributes, forms, etc, should be resolved if they ever come up? (each vendor is free to define them as they wish, so it could be that multiple vendors have different definitions of the same code/number & would be ambiguous) I don’t see any reason to block this patch if it doesn’t have such a conflict, since there are already other vendor extension codes supported here for a variety of vendors - but does make me wonder.

This'll need a test case, in any case.

Adrian/Paul: Pondering this, any thoughts on how conflicts in the vendor extension range of attributes, forms, etc, should be resolved if they ever come up? (each vendor is free to define them as they wish, so it could be that multiple vendors have different definitions of the same code/number & would be ambiguous) I don't see any reason to block this patch if it doesn't have such a conflict, since there are already other vendor extension codes supported here for a variety of vendors - but does make me wonder.

We will have to solve it by special-casing the ID and providing a command-line option if we can't disambiguate the true nam/meaning from the context. (E.g., if there was a hypothetical APPLE extension conflicting with a SUN extension and the object file is Mach-O then we could deduce that we should decide for the APPLE extension).

Let's hope we don't have to, though.

On a related note — it would be great if we could import all vendor extensions specified in David Anderson's libdwarf into LLVM.

-- adrian

This’ll need a test case, in any case.

In case you’re wondering, one way to do this would be to add an assembler source file, compile it and run it through llvm-dwarfdump.
Alternatively you can use the new yaml2obj tool that is being developed.

– adrian

The patch should probably define a new vendor code for SUN rather than re-use GNU. And it needs a test.

We’ve been fortunate (or maybe it’s a testament to the care exercised by people who define extensions) to see no conflicts in vendor extensions. If/when it ever comes up we’ll have to do something, I think Adrian had a pretty reasonable idea.

–paulr

This'll need a test case, in any case.

In case you're wondering, one way to do this would be to add an assembler source file, compile it and run it through llvm-dwarfdump.

cool, can you point me at an existing one that i can use as a reference?

Alternatively you can use the new yaml2obj tool that is being developed.

ill try the first suggestion for now.

cheers,
dlg

This'll need a test case, in any case.

In case you're wondering, one way to do this would be to add an assembler source file, compile it and run it through llvm-dwarfdump.

cool, can you point me at an existing one that i can use as a reference?

Here's a very recent example:

https://reviews.llvm.org/D32618

i got some time to go back to this and had a look at the code here. it's a bit... overwhelming...

also, i need some direction on what im supposed to test with regards to this flag? do i provide asm for two functions, one with the flag and one without and verify that they make it through the compiler?

dlg