[PATCH] D21552: [ELF] - Teach llvm-readobj to print dependencies of SHT_GNU_verdef and refactor dumping method.

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 22 01:14:43 PDT 2016


grimar added inline comments.

================
Comment at: tools/llvm-readobj/ELFDumper.cpp:570
@@ +569,3 @@
+
+    DictScope Dep(W, "Dependencies");
+    const uint8_t *PAux = P + VD->vd_aux + VD->getAux()->vda_next;
----------------
grimar wrote:
> grimar wrote:
> > rafael wrote:
> > > The "spec" used the name "predecessor versions". Maybe this should be "Predecessors". I assume that if you have
> > > 
> > > foo {
> > > } bar;
> > > 
> > > bar {
> > > } zed;
> > > 
> > > it will chain them?
> > > 
> > > If that is the case, maybe it would be better to print just the first predecessor?
> > > 
> > > In any case, I agree with Davide, we need a test :-)
> > No, it will not chain. Foo will have [foo, bar], where bar is dependency. Bar will have [bar, zed].
> > About terminology, I used sun docs: https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter6-61174/index.html, it says "version dependencies".
> > 
> > And like I wrote in my answer to Davide, I was unable to get more than one "dependency", so looks "predecessor" word is more correct here.
> > So I plan to use it and print predecessor without a loop.
> Ah, I was mean: "yes, it will chain" zed<-bar<-foo, but will not add zed as a "dependency" for bar.
*for foo
sorry :)


http://reviews.llvm.org/D21552





More information about the llvm-commits mailing list