labath added a comment.

In D84008#2161243 <https://reviews.llvm.org/D84008#2161243>, @Higuoxing wrote:

> In D84008#2160426 <https://reviews.llvm.org/D84008#2160426>, @MaskRay wrote:
>
> > The number of changed tests is large. Is it worth moving the 
> > `IO.mapOptional("Length", Unit.Length);` change to a separate patch to make 
> > the refactoring more focused? Thanks
>
>
> This patch is intended to make the length field be inferred when emitting the 
> .debug_info section. If we move the `IO.mapOption("Length", Unit.Length);` 
> change to a separate change, we might not be able to know when to infer the 
> length? There are two visitors, `DumpVisitor` which is used to emit the 
> .debug_info section and `DIEFixupVisitor` which is used to calculate the 
> length field for us. Do you mean that we keep the `DIEFixupVisitor` class and 
> remove the `DumpVisitor` class in this patch?


I think that should work if you make it so that this other patch comes before 
the functional change in this patch. That other patch could change the encoding 
to hex (`uint64_t Length;` -> `yaml::Hex64 Length;`) and make it default to 
zero (`IO.mapRequired("Length", Unit.Length);` -> `IO.mapOptional("Length", 
Unit.Length, 0);`). That should have no functional change (I think), but allow 
you to make the changes in all the yaml files. The visitation stuff could come 
after that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84008/new/

https://reviews.llvm.org/D84008



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to