On Thu, Aug 1, 2019 at 8:38 PM Pavel Labath <pa...@labath.sk> wrote: > On 01/08/2019 14:34, Fangrui Song via lldb-commits wrote: > > Author: maskray > > Date: Thu Aug 1 05:34:43 2019 > > New Revision: 367549 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=367549&view=rev > > Log: > > [lit] Use ld.lld -z separate-code to work around a debug_line parsing bug > > > > The issue was exposed by D64903/r367537. > > http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7321/ > > > > In these tests, .debug_str immediately follows .text. > > The last section of last RX PT_LOAD was originally padded with trap > > instructions and .debug_str started at a new page (actually > > common-page-size). Now, .debug_str immediately follows .test. > > Add -z separate-code to use the old layout. > > > > > Thanks, I was about to commit the same patch. > > For future reference, here is my analysis I was going to put into the > commit message: > > --- > The lld patch changed how it lays out data in segments, which was > resulted in the tiny test funclets being at the very end of a PT_LOAD > segment. This exposed a bug where lldb does not correctly handle line > table end-of-sequence entries to the very end of a section (so the byte > they point to does not actually belong to any section). > > This is mostly bening in practice, as the code handling line tables will > terminate as soon as it is not able to resolve an address, which is > something that would happen after reading the end-of-sequence entry > anyway. However, these tests assert that we are actually able to parse > and display the end entry itself, and so they fail. > --- >
Thanks for the enlightening comment! I'll play with it to learn more about the mechanism. -- 宋方睿
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
