This is an archive of the discontinued LLVM Phabricator instance.

[obj2yaml] - Add support of dumping archives.
AbandonedPublic

Authored by grimar on Oct 19 2020, 4:59 AM.

Details

Summary

Currently obj2yaml does not support dumping archives.
With this change the behavior changed to:

  1. Try to extract each binary one by one and try to dump it.
  2. Report an error and skip a binary when it is not possible to dump it.

Diff Detail

Event Timeline

grimar created this revision.Oct 19 2020, 4:59 AM
Herald added a project: Restricted Project. ยท View Herald TranscriptOct 19 2020, 4:59 AM
grimar requested review of this revision.Oct 19 2020, 4:59 AM

What's the use case for this? I don't follow why you can't just use llvm-ar to extract the files and then run obj2yaml on them individually.

There was a TODO in the code that suggested to fix this. I think this is also consistent with other tools behavior, e.g with llvm-readelf.

Honestly, I'm not convinced that just because we can, we should. There are good reasons for other tools like llvm-readelf to run over all archive members, but obj2yaml isn't, to my knowledge, used in a production environment or even in a testing environment where such functionality would prove particularly useful. Increasing code complexity in order to support it seems unwise to me.

I actually think there might be a slightly different approach to this, for which there might be a use-case: rather than dumping individual YAML blocks, add them all as "children" for an archive YAML block. That way, you can also see the non-binary members of the archive, e.g. the symbol table and the string table. This is probably more useful for the yaml2obj side, to allow testing of malformed archives in llvm-ar testing.

Honestly, I'm not convinced that just because we can, we should. There are good reasons for other tools like llvm-readelf to run over all archive members, but obj2yaml isn't, to my knowledge, used in a production environment or even in a testing environment where such functionality would prove particularly useful. Increasing code complexity in order to support it seems unwise to me.

OK.

I actually think there might be a slightly different approach to this, for which there might be a use-case: rather than dumping individual YAML blocks, add them all as "children" for an archive YAML block. That way, you can also see the non-binary members of the archive, e.g. the symbol table and the string table. This is probably more useful for the yaml2obj side, to allow testing of malformed archives in llvm-ar testing.

I thought about it (as an independent feature/option though) too. It could be useful for tests like https://github.com/llvm/llvm-project/blob/master/llvm/test/tools/llvm-objdump/malformed-archives.test,
which is currently has 14 precompiled broken archives, which are a bit hard to invesigate (at least for me it was, when I tried to craft a last test case for this patch).

I've even started to dig into format details of archives. Going to invesigate how to implement it for yaml2obj/obj2yaml.

grimar abandoned this revision.Oct 22 2020, 1:53 AM

Abandoning. As discussed, going to post a patch for obj2yaml/yaml2obj to support dumping/crafting archives very soon instead.

Abandoning. As discussed, going to post a patch for obj2yaml/yaml2obj to support dumping/crafting archives very soon instead.

An archive header with Children fields referencing some filenames/opaque contents? I think it might be useful.