[lld] r361830 - Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the sections were discarded

[Fāng-ruì Sòng via llvm-commits]

Stephan, sorry, I missed your email. As Hans said,
https://bugs.chromium.org/p/chromium/issues/detail?id=978067 may be
related. We are investigating the issue.

The revert may be a bit tricky.. I need to figure out why r362739 was a
failed revert then..

On Tue, Jun 25, 2019 at 9:25 PM Hans Wennborg <hans at chromium.org> wrote:

> We're seeing debug info problems in Chromium/V8 too after this:
> https://bugs.chromium.org/p/chromium/issues/detail?id=978067
>
> On Fri, Jun 7, 2019 at 9:18 AM Stephan Bergmann via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> >
> > With bisecting, I found that the below commit breaks the debuginfo in my
> > Linux LibreOffice builds that use lld with --gdb-index.  I wasn't able
> > to reduce the test case in any meaningful way, but what I observe is
> > that a gdb backtrace will print source information for some of the
> > frames, but for others will only print the .so pathname.  I could not
> > reproduce with a small test executable, but the shared libraries
> > involved in LibreOffice can be rather large, so maybe the issue is
> > related to size.  The backtraces look fine when I rebuild LibreOffice
> > without using --gdb-index (though I appear to have some issue with
> > "step" commands in gdb not stepping into function calls even then, but
> > didn't investigate that further).
> >
> > (I see that this commit has yesterday been reverted in r362739 and then
> > re-reverted in r362743, so I assume the situation on trunk hasn't
> > effectively changed from what I observed with my build from earlier this
> > week.)
> >
> > On 28/05/2019 16:34, Fangrui Song via llvm-commits wrote:
> > > Author: maskray
> > > Date: Tue May 28 07:34:28 2019
> > > New Revision: 361830
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=361830&view=rev
> > > Log:
> > > Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the
> sections were discarded
> > >
> > > This is implemented by creating Undefined (instead of Defined) for such
> > > local STT_SECTION symbols. It allows us to catch errors when there are
> > > relocations to such discarded sections (e.g. in PR41693, ld.bfd and
> gold
> > > error but we don't). Updated comdat-discarded-error.s checks we emit
> > > friendly error message.
> > >
> > > For relocatable-eh-frame.s, ld.lld -r a.o a.o will now error
> > > "STT_SECTION symbol should be defined" because the section .eh_frame
> > > refers to is now an Undefined instead of a Defined.
> > > So I have to change `error()` to `warn()` to retain the output.
> > >
> > > rLLD361144 inadvertently enabled the error for --gdb-index
> > > (in LLDDwarfObj<ELFT>::findAux()).
> > >
> > > Relocations from .debug_info (not in comdat) to .text.* (in comdat) for
> > > DW_AT_low_pc are common. If an .text.* was discarded, rLLD361144 would
> error,
> > > which was unexpected. (Note, if we don't error as this patch does,
> > > InputSection::relocateNonAlloc() will resolve such relocations).
> > >
> > > Added:
> > >      lld/trunk/test/ELF/comdat-discarded-gdb-index.s
> > > Modified:
> > >      lld/trunk/ELF/DWARF.cpp
> > >      lld/trunk/ELF/InputFiles.cpp
> > >      lld/trunk/ELF/InputSection.cpp
> > >      lld/trunk/ELF/Relocations.cpp
> > >      lld/trunk/test/ELF/comdat-discarded-error.s
> > >      lld/trunk/test/ELF/comdat-discarded-reloc.s
> > >      lld/trunk/test/ELF/comdat.s
> > >      lld/trunk/test/ELF/invalid-undef-section-symbol.test
> > >      lld/trunk/test/ELF/relocatable-eh-frame.s
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>


-- 
宋方睿
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190625/b8202d82/attachment.html>