llvm dev - Jan 2020 - DWARF debug line error handling changes

On 28/01/2020 20:37, David Blaikie via llvm-dev wrote:
> and one idea I had was to have the DWARFDataExtractor return a new
> DWARFDataExtractor that was specifically bounded to the parsed length
> for this reason.
I think this would be great. In fact, I was getting ready to propose
something like that myself. :)

FWIW, lldb DataExtractors already support this kind of slicing.

pl

On Wed, Jan 29, 2020 at 2:28 AM Pavel Labath <pavel at labath.sk> wrote:
> On 28/01/2020 20:37, David Blaikie via llvm-dev wrote:
> > and one idea I had was to have the DWARFDataExtractor return a new
> > DWARFDataExtractor that was specifically bounded to the parsed length
> > for this reason.
>
> I think this would be great. In fact, I was getting ready to propose
> something like that myself. :)
>
> FWIW, lldb DataExtractors already support this kind of slicing.
>
Oh, great - I'm sort of inundated with code reviews and things these days -
so could I prevail upon you to implement that & pick up some of these line
table reviews to either coax the use of such an entity there, or port a few
places (at least all the DWARF32/64 length parsing duplicates - there's 3-4
copies of the code that does the 32/64 length dance and validates the
length of a header or similar in there)?

Tagged you in a few reviews (some committed already/approved - but places
that could benefit from cleanup with such a device)
https://reviews.llvm.org/D72155 https://reviews.llvm.org/D73618
https://reviews.llvm.org/D72900
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200130/78cdbe55/attachment.html>

On 31/01/2020 01:31, David Blaikie wrote:
> 
> 
> On Wed, Jan 29, 2020 at 2:28 AM Pavel Labath <pavel at labath.sk
> <mailto:pavel at labath.sk>> wrote:
> 
>     On 28/01/2020 20:37, David Blaikie via llvm-dev wrote:
>     > and one idea I had was to have the DWARFDataExtractor return a new
>     > DWARFDataExtractor that was specifically bounded to the parsed
length
>     > for this reason.
> 
>     I think this would be great. In fact, I was getting ready to propose
>     something like that myself. :)
> 
>     FWIW, lldb DataExtractors already support this kind of slicing.
> 
> 
> Oh, great - I'm sort of inundated with code reviews and things these
> days - so could I prevail upon you to implement that & pick up some of
> these line table reviews to either coax the use of such an entity there,
> or port a few places (at least all the DWARF32/64 length parsing
> duplicates - there's 3-4 copies of the code that does the 32/64 length
> dance and validates the length of a header or similar in there)?
> 
> Tagged you in a few reviews (some committed already/approved - but
> places that could benefit from cleanup with such a
>
device) https://reviews.llvm.org/D72155 https://reviews.llvm.org/D73618 https://reviews.llvm.org/D72900
> 
>  
Thanks.

Well, I am afraid in this case, "getting ready" is a pretty long-term
process :/, and I don't think I'll be able to get to this next week,
because I'll be travelling.

But I think I should be able to squeeze that in the week after that.

pl