This is an archive of the discontinued LLVM Phabricator instance.

[DWARF] - Cleanup relocations proccessing.
ClosedPublic

Authored by grimar on May 15 2017, 6:27 AM.

Details

Summary

There was 3 visible problem this patch trying to fix:

  1. RelocAddrMap was defined at 2 difference files at once. I moved definition to DWARFRelocMap.h.
  2. RelocAddrMap was a pair of <width, address>, where width is relocation size (4/8), and width field was never used in code.
  3. Relocations proccessing loop had checks for width field. I don't think DWARF parser should do that. There is probably no much sense to validate relocations during proccessing them in parser.

Patch moves definition to single file, stops storing width field, stops doing additional checks during handling
of relocations, that all together simplifies the code.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar created this revision.May 15 2017, 6:27 AM
aprantl edited edge metadata.May 15 2017, 9:44 AM

I'm assuming the checks are removed because they are already done elsewhere?

I'm assuming the checks are removed because they are already done elsewhere?

Let me explain in details my position. Lets take a look more closer what was checked.
There was 2 checks I removed:

  1. if (Address + R.Width > SectionSize) { ...
  2. if (R.Width > 8)

R.Width field is just a size of a relocation. For example for x86_64 target it can be 4 or 8 usually:

RelocToApply visitELF_X86_64_64(RelocationRef R, uint64_t Value) {
  int64_t Addend = getELFAddend(R);
  return RelocToApply(Value + Addend, 8);
}
RelocToApply visitELF_X86_64_PC32(RelocationRef R, uint64_t Value) {
  int64_t Addend = getELFAddend(R);
  uint64_t Address = R.getOffset();
  return RelocToApply(Value + Addend - Address, 4);
}

That means that first check is always true until implementation of relocation visitor is correct and
until we do not trying to parse broken object. Implementation issues should be checked in testcases,
and not in code. And broken inputs is unlikely can cause problem here. If we have broken input, it is ok to produce
broken dump. Does not seem that DWARF parsers really should check that relocations produced by compiler are correct in a hot loop ?

Second check tests that relocation size is <= 8. I do not know why it was checked, because Width is unused in code at all.
If something wrong with such relocations, then visitor should report an error "failed to compute relocation" that we still handle.
So check looks never triggers while visitor implementation is correct. Currently (RelocVisitor.h) never returns width > 8.

aprantl accepted this revision.May 16 2017, 9:28 AM
This revision is now accepted and ready to land.May 16 2017, 9:28 AM

Thanks for review, Adrian !

I am planning to commit this after D33184 probably, because
we have RelocAddrEntry now:

struct RelocAddrEntry {
  uint8_t Width;
  int64_t Value;
};
typedef DenseMap<uint64_t, RelocAddrEntry> RelocAddrMap;

And if I remove Width field, like this patch do, then struct with single field
would look unreasonable. D33184 adds one more field and should look fine.

On the other side I would like to have this check removed because going to post another patch where this cleanup
is used heavely. So I am going to commit this.

If it is not ok to temporarily have single member in RelocAddrEntry, I'll remove this struct separatelly, though I would suggest just
to wait for D33184 which looks promising, it will use this struct anyways.

This revision was automatically updated to reflect the committed changes.