Review request: generate DWARF pubnames under a compiler option

[Eric Christopher]

On Mon, Feb 11, 2013 at 2:15 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

> On 2/11/2013 1:21 PM, Eric Christopher wrote:
>
>>
>> Missing a testcase it appears as well? Once you've got a testcase and
>> have fixed the above feel free to commit if you have commit privs,
>> otherwise send me something. It'd be nice to split out the section
>> patches from the dwarfdump and emission patch. Try to make sure in the
>> testcase that you cover a good set of what should be in the pubnames
>> section and include the .c file in the comments of the testcase so we
>> can duplicate it via clang's IR emission.
>>
>
> Interestingly, I had a testcase like that, and it did include the original
> source in the comments.  It just somehow didn't make it to my local commiy.
>  One thing I wasn't sure about it is that I put it in the X86-specific test
> directory.  Here's a snippet explaining why:
>
> ; Test this on x86 because it is known to use ELF.  This way we can use
> ; the actual section name to make sure that the symbol names are defined
> ; inside of it.
> ;
> ; CHECK: pubnames_begin0
> ; This test will fail if these names are emitted in a different order.
> ; CHECK: global_namespace_variable
> ; CHECK: global_namespace_function
> ; CHECK: static_member_function
> ; CHECK: global_variable
> ; CHECK: global_function
> ; CHECK: member_function
> ; CHECK: pubnames_end0
>
>
> There is also the complication related to the order of the names.  Are you
> ok with this, or do you have another suggestion?
>

Mmm.. I'd prefer you use llvm-dwarfdump after making an object file with
it. Also, I'd hope that whatever way you're iterating over the list is
stable. I didn't think to check that, so if it isn't please make sure it
is. I don't think there's a reason to make this x86 only since all of the
strings for the pubnames section have to be actual strings and so won't be
subject to the unimplemented relocation problem.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130211/2c47249b/attachment.html>