labath added a comment. In D75929#1916127 <https://reviews.llvm.org/D75929#1916127>, @ikudrin wrote:
> I believe that this patch is more or less compatible with any approach which > might be taken. The idea is that there is a set of constants for internal use > and functions to translate them to/from external representation and both > constants and translation functions might be adjusted when needed. In any > case, the general design remains the same. That's true, but I'm not sure it is really the best solution. This way we will have three numbering schemes (four if you count the "index" thingy in llvm-dwp) floating around: the "gnu" scheme, the "official" scheme, and the "internal" scheme. That's quite a lot to keep in ones head at once. I'm wondering if if wouldn't be simpler to have two complete enums -- with the "gnu" scheme, and one with the "official" scheme -- and then to internally use the enum matching the on-disk format currently in use. To insulate the users from having to guess the right enum to use, we could add a series of accessors: `getLocOffset`, `getMacInfoOffset`, ..., which would use the appropriate enum based on the index version (or assert if there is no such constant in the given version). WDYT? Regardless of the outcome of that, I think it would be good to split this patch up and separate the enum shuffling from the new functionality (does this only add parsing support for v5 indexes, or is there something more?). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75929/new/ https://reviews.llvm.org/D75929 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
