This is an archive of the discontinued LLVM Phabricator instance.

[YAML] - Teach yaml2obj/obj2yaml to work with numeric relocation values.
ClosedPublic

Authored by grimar on Jun 28 2017, 8:57 AM.

Details

Summary

That may be useful if we want to produce object containing broken relocation values
using yaml2obj.

Previously that was impossible because only enum values were parsed correctly, this patch
allows to put any numeric value as a relocation type.

We already use precompiled binary to check broken relocation handling in LLD, and today I faced
again that need a way to produce a object with different broken relocations for another patch.
I think yaml2obj should be able to do that out of box. Patch implements the support.

Sorry, not sure about how much list of reviewers is appropriate, it seems many people
worked on yaml relative things.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar created this revision.Jun 28 2017, 8:57 AM
ruiu edited edge metadata.Jun 28 2017, 10:17 AM

It seems you can do this without modifying YAMLTraits.h. You can set some invalid value (such as -1) to Value at beginning of ScalarEnumerationTraits<ELFYAML::ELF_REL>::enumeration and then check if it still has the invalid value after the switch.

grimar added a comment.EditedJun 29 2017, 1:24 AM
In D34758#794033, @ruiu wrote:

It seems you can do this without modifying YAMLTraits.h. You can set some invalid value (such as -1) to Value at beginning of ScalarEnumerationTraits<ELFYAML::ELF_REL>::enumeration and then check if it still has the invalid value after the switch.

That will work for jaml2obj case, but will not work for case when IO.outputting() == true unfortunately (obj2yaml case).

In the latter case Value will have some value read from object. Then IO.enumCase() calls Output::matchEnumScalar(), which sets EnumerationMatchFound to true if enumeration was
matched. This flag can be used to check that we found the enumeration, but it is private and I would prefer not to add accessor for it, its a part of internal implementation
and too specific thing to provide access to, probably.

That is why I added return value to enumCase() instead. It looks more clear for my eye when enumCase() just can say whether it was able to handle the case or not.

grimar updated this revision to Diff 104657.Jun 29 2017, 8:34 AM
  • Change implementation just to use IO.enumFallback​() instead all code.
ruiu accepted this revision.Jun 29 2017, 8:48 AM

LGTM

test/Object/X86/yaml-elf-x86-rel-broken.yaml
21–24 ↗(On Diff #104657)

You want to check only this.

This revision is now accepted and ready to land.Jun 29 2017, 8:48 AM
This revision was automatically updated to reflect the committed changes.