[llvm-branch-commits] [llvm] [llvm-readobj][ELF] Print the relocation of each --stack-sizes entry (PR #232332)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 requested changes to this pull request.

I'm not convinced by this, for similar reasoning to my concerns [here](https://github.com/llvm/llvm-project/pull/213156#discussion_r4205043127), but also because the name is right there in the Functions array. I understand that in some cases the relocation might be a section relative one instead of a symbol one, but in that case, the problem lies in the output in this new Relocations block.

What problem are you actually trying to solve, concretely? Why do you need to know what relocation impacts the resolution and why is it not sufficient to simply dump the relocations for the stack sizes section separately and marry the two up? I could support printing the offset of the stack sizes entry, if needed to achieve this (but its inferrable from the index, so I'd prefer not to do that).

More generally, I think our dumping tools should be dumping what's in the section and minimising the amount of information dumped under a single option when that information can be inferred from elsewhere. If we start getting into the realm of dumping inferred information that might be useful to some clients, we would end up with excessively noisy dumping output, making it harder for other clients to interpret the data for the cases they care about. 

You could argue that the function names are inferred too. The typical (I'd go as far as to say fundamental) use case for this section is "which of my functions contribute the most to my stack size", so we need to print this inferred information. The same isn't true about the relocations used to derive that information.

NB: This comment specifically is about the relocation entries in the stack sizes output. I'm okay with the printing of the address field, because that's stored in the entry directly, so you're not inferring information in this case (and I'd be tempted to print 0/the stored addend for ET_REL objects, for consistency with other objects, but I could also see an argument for not printing these in this case).

Pinging @MaskRay to get his thoughts, since he's the other key maintainer of llvm-readobj.

https://github.com/llvm/llvm-project/pull/232332