================ @@ -222,14 +224,32 @@ Sections: ## Check we don't dump anything except the file header when the section header table can't be read. # RUN: not llvm-readobj -a %t.invalid1 2>&1 \ -# RUN: | FileCheck %s -DFILE=%t.invalid1 -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-LLVM +# RUN: | FileCheck %s -DFILE=%t.invalid1 -DSECHDROFF=0x1000 -DPHDRCOUNT="0" -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-LLVM # RUN: not llvm-readelf -a %t.invalid1 2>&1 \ -# RUN: | FileCheck %s -DFILE=%t.invalid1 -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-GNU +# RUN: | FileCheck %s -DFILE=%t.invalid1 -DSECHDROFF=4096 -DPHDRCOUNT="0" -DSECHDRCOUNT=8192 -DSECHDRSTRTABINDEX=12288 --check-prefix=INVALID-GNU ## Check what we print when e_shnum == 0, e_shstrndx == SHN_XINDEX and the section header table can't be read. +## TODO: We should not report LLVM-BAD-PHDR and GNU-BAD-PHDR in the future since these are duplicate errors. ---------------- aokblast wrote:
The "duplication" noted previously appears to be a false positive resulting from two factors: 1. While llvm-readelf typically defers error reporting, getShNum() and getPhNum() emits an error immediately. 2. In ELFDumper.cpp, getProgramHeadersNumString() uses Obj.getPhNum(), which reports an error even when the failure isn't strictly related to reading e_phnum. Although the issue of phnum logic triggering e_shnum errors was addressed in [here](https://github.com/llvm/llvm-project/pull/181796#discussion_r2851640884), adopting the new getShNum() interface for getSectionHeadersNumString() would likely reintroduce this redundant error reporting. https://github.com/llvm/llvm-project/pull/165278 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
