[Lldb-commits] [lldb] r367549 - [lit] Use ld.lld -z separate-code to work around a debug_line parsing bug

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

On Thu, Aug 1, 2019 at 8:38 PM Pavel Labath <pavel at 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.

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