labath added a comment. In https://reviews.llvm.org/D40616#951324, @clayborg wrote:
> I think GetFileSize() should remain the number of bytes of the section on > disk and we should add new API if we need to figure out the decompressed > size. Or maybe when we get bytes from a compressed section we are expected to > always just get the raw bytes, then we check of the section is compressed, > and if so, then we call another API on ObjectFile to decompress the data. So > I would prefer GetFileSize() to return the file size of the section size in > the file and not the decompressed size. Is there a way to make this work? Yes, that's possible. The first version of this patch had GetFileSize return the on-disk size, but it was weird because then GetSectionData returned a different size. I guess it would stop being "weird" if we add an extra `GetDecompressedSize` method and document that `GetSectionData` returns decompressed data. I don't think we can use `GetByteSize` to return the decompressed size, as we use this value to denote the size in the process memory, and expect it to be zero for non-loadable sections. It is true that the elf spec says no loadable section can be compressed, so we theoretically wouldn't have a conflict here, but I don't think we will be doing anyone a favour by overloading GetByteSize this way. I don't like the idea of needing to do an extra call to decompress data, as it will complicate clients and I think all clients will want to use the data in the decompressed form. https://reviews.llvm.org/D40616 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
