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

Tue Jun 25 08:46:12 PDT 2019

I've reverted in r364321, hopefully without breaking anything else.

On Tue, Jun 25, 2019 at 4:27 PM Fāng-ruì Sòng <maskray at google.com> wrote:
>
> 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
>
>
>
> --
> 宋方睿