[PATCH] D63280: [llvm-objdump] Use <first-symbol>-<offset> as the section start symbol

Yuanfang Chen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 13 20:57:03 PDT 2019


ychen added a comment.

In D63280#1542942 <https://reviews.llvm.org/D63280#1542942>, @MaskRay wrote:

> In D63280#1542922 <https://reviews.llvm.org/D63280#1542922>, @ychen wrote:
>
> > In D63280#1542919 <https://reviews.llvm.org/D63280#1542919>, @MaskRay wrote:
> >
> > > In the context of PR41946:
> > >
> > >   Disassembly of section .text:
> > >  
> > >   0000000000001000 .text:
> > >       1000: 90                            nop
> > >
> > >
> > > I agree that `0000000000001000 .text:` is not useful as it repeats what `Disassembly of section .text:` says. However, in the `bar at plt-0x10` case (when the PLT resolver stub doesn't get a symbol name), I'm not sure this improves readability.
> >
> >
> > I agree it is not very readable but it matches GNU output.
>
>
> I know this what GNU objdump does:) While working on lld's ppc32/riscv .plt support recently, I constantly see the annoying `__libc_start_main at plt-0x20` as a branch target. Compatibility is important, for people who use llvm-objdump as a drop-in replacement of GNU objectdump. However, in some places, where there are several ways to do a thing (e.g. how to render `.plt`), I believe we do not necessarily copy its behavior if we can find better ways.
>
> Having said this, `.plt` looking better than `blah at plt-0x20` is my opinion. Other reviewers may have different ideas. I don't mind changing it to `blah at plt-0x20` if the majority of reviewers agree so.


`.plt` definitely looks better for the case. I don't have a strong opinion for each. Looks like it is (consistency+compatibility-with-GNU vs readability).  I'm slightly in favor of consistency as a light user of binary tools.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63280/new/

https://reviews.llvm.org/D63280





More information about the llvm-commits mailing list