If a Section had Type SHT_STRTAB (which could happen if you had a .dynstr section) it was possible to cast Section to StringTableSection and get away with any operation that was supported by SectionBase without it being noticed. This change makes this bug easier to notice and fixes it where it occurred. It also made me realize that there was some duplication of efforts in the loop that calls ::initialize. These issues are all fixed by this change.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
So, from what I can see, it is no longer a requirement for a dynamic section (or indeed any "SectionWithStrTab" instance) to refer to a section of type SHT_STRTAB? Is this desirable, because it sounds a bit odd to me? I could support a check in SectionWithStrtab::initialize that checks the actual type of the string table. Otherwise, this change looks reasonable to me.
tools/llvm-objcopy/Object.h | ||
---|---|---|
119 ↗ | (On Diff #116866) | As this class is now only usable for non-alloc string table sections, I think that we need to explicitly say so in the comment, along with the reason why. |
I think a check is a good idea. In fact I thought I added that check; not sure why it didn't make it to review.
- Added comment explaining why classof works the way it does.
- Added check for SHT_STRTAB
I'm starting to notice a slightly non-trivial match up between classof and makeSection. Is there a way we could make this precise? Ideally I'd like to somehow contain the means of construction for a type within the class itself. I'd really like the following properties to be enforced by the library
- You can't construct a StringTableSection that dosn't pass StringTableSection::classof
- The checks for SHT_* and SHF_ALLOC shouldn't be duplicated in construction and classof. When one changes the other should change as well.