Should llvm-objdump/objdump Display Actual Corrupted Values in Malformed ELF Files?

Community LLVM Foundation
1

When using llvm-objdump (or GNU objdump) to inspect malformed ELF files, the output sometimes contains seemingly random characters, such as:

Dynamic Section:
  NEEDED               D
  SONAME               U
  RPATH                f
  RUNPATH              w

These characters don’t provide meaningful information. Would it be better if the tool instead displayed the actual corrupted values, like this?

Dynamic Section:
  NEEDED               0xffffffffbe5a0b5f
  SONAME               0xffffffffbe5a0b6f
  RUNPATH              0x0000000000000007

This approach would make it clearer that the values are corrupted rather than displaying arbitrary characters. Thoughts?

2

My first question is, what does GNU objdump do in this case? If GNU objdump has sensible-looking prior art, we should aim to mirror it. If it doesn’t, I believe we are free to diverge where the output doesn’t otherwise make sense.

Personally, I think printing a warning would be the right thing to do. I do think there would be a benefit in having the raw entry values in such cases, but only if it’s reasonably straightforward to do so in the code.

3

Thanks for your response! I understand now.

I’m currently working on a patch to implement this change. This patch was originally intended to resolve #86612, but while working on it, I noticed that the output (as described above) might be invalid. That’s why I raised this question.

Would it be better to split this into two separate patches? Also, is this patch eligible for merging?

Additionally, some tests have failed—what steps should I take to resolve these issues and move forward with the merge?

4

If you’d like a patch to be merged, you need to follow the LLVM guidelines for submitting a patch.

If you’re referring to lit tests, you’ll need to either update the tests or fix your patch, depending on what the issue is, as part of your patch. It’s hard to identify what the right approach is without seeing the failures. You’ll also need to make sure you have test coverage for the update you are making, which might require a new test or update an existing one.