[PATCH] D21503: [llvm-dwarfdump] - Teach dwarfdump to dump gdb-index section.

[George Rimar via llvm-commits]

???>dump is void, but parse is not - though it seems like parse failures, as I said, usually just result in not printing anything.

>If you want to save off the state and print a failure, that's cool. Test cases desired, etc.

Ok, I would like to start from little then, I simplified code, removed Error state.
I do not like idea to make parse return bool here as it then can spread the checks somewhere outside.
Currently just getGdbIndex().?dump(...) is called, where first part calls parse inside and dump() prints the result depending on state.
Looks ok ?

> That's probably not something to test here, though - this dumps the contents of the table even if the hashing/filling is incorrect. In the implementation of the index, dumping complex cases that trigger the various hashing behavior would be > appropriate.

But we still might want to check if the hash is correct in future. For example version 4 of format has different hash formula than later versions.

> I'm interested in making sure the test for parsing is focused on that and it's clear what's being tested and why.
>
> To make this more concrete: What benefit does having double, float, and int in the first file provide? I see that double is a shared type, float and int are non-shared types - would one suffice, rather than two?
> Is there interesting coverage in having a non- shared type in both files (float or int in one, bool in the other) or would one suffice?

My my point here was that it can be possible benefit for coverage to have a bit more values.
Have few names to see that few values are different, but not only 1 or 2 of them, for example.

?Something very very minimal for this testcase probably is:
2 methods in 2 objects with the same return type. That allows to see at least 2 address area entries, 2 CU and return type will be shared, this also gives 3 strings in symtable and 3 entries in constant pool.

I updated the patch and testcase to above one to demonstrate.
I am not sure it was worth to reduce that much, but if you think it is better, let see how it works.

George.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160918/1208cff9/attachment.html>