In D93362#2500294, @grimar wrote:

In D93362#2499834, @haowei wrote:

For the case to test error message when sh_size % sh_entsize is not 0, I didn't find any good examples that I can manipulate the sh_entsize through yaml2obj. Do you have good suggestions to write unit tests for these cases?

Can you elaborate what the problem is? There are many examples in both yaml2obj and llvm-readelf test suites that are using the EntSize key to set the sh_entsize.

In D93362#2497437, @jhenderson wrote:

Is it important that the .dynsym is used directly when .hash/.gnu.hash is available? At the moment, your test doesn't really show whether it is used or whether you go straight to the dynamic tags for details, I believe - to do that, you'd need to have one given bogus values for the size, and show that this is not sued. Additionally, you have no testing for your error messages, nor do you have testing that shows that the .gnu.hash is used above the .hash section.

In D93362#2492168, @jhenderson wrote:

In D93362#2492101, @haowei wrote:

I rebased the code, it seems upset the Phabricator since it does not distinguish between rebase changes and actual changes.

What do you mean it seems upset? The review here looks fine to me.

If I compare Diff 2 and Diff 3 in Phabricator, the result looks weird as rebase changes were included.

fix some code style issues.

I rebased the code, it seems upset the Phabricator since it does not distinguish between rebase changes and actual changes.

An updated version was landed in f4c26d993bdc . This diff is no longer needed.

An updated version was landed in f4c26d993bdc . This diff is no longer needed.

An updated version was landed in f4c26d993bdc . This diff is no longer needed.

An updated version was landed in f4c26d993bdc . This diff is no longer needed.

An updated version was landed in f4c26d993bdc . This diff is no longer needed.

An updated version was landed in f4c26d993bdc . This diff is no longer needed.

friendly ping.

fix test on mac

In D92902#2474539, @thakis wrote:

Looks like this breaks tests on mac: http://45.33.8.238/macm1/897/step_10.txt

Please take a look, and revert for now if it takes a while to fix.

Change was reverted. Looks like touch on bsd behaves differently from the gnu one.

In D92902#2468951, @MaskRay wrote:

--preserve-dates in this utility is different from --preserve-dates in GNU/LLVM objcopy, so I am a bit unsure this is the right name. In llvm-tblgen such an option is called --write-if-changed

In D93362#2460124, @jhenderson wrote:

What others said - there are six cases we should care about:

1. Section headers are stripped and the ELF has no hash/gnu_hash dynamic tag - this can be treated as an error, I think since the ELF gABI requires a hash table.
2. Section headers are stripped, but there is a DT_HASH
3. Section headers are stripped, but there is a DT_GNU_HASH
4. Section headers present but there is no .hash or .gnu.hash section - this might be treated as an error, I think since the ELF gABI requires a hash table.
5. Section headers present with .hash section
6. Section headers present with .gnu.hash section

I think all of the tools should handle all of these situations (llvm-readelf, llvm-objdump, llvm-elfabi, ...) so it definitely seems like this should be part of the Object library.

Add this feature to ELF Stub output as well.

Address review comments.

LGTM

In D91223#2415137, @MaskRay wrote:

@haowei https://llvm.org/docs/DeveloperPolicy.html#commit-messages Please use git commit --amend --author for future patches where the majority of the work is done by others.

In D66324#2394687, @lebedev.ri wrote:

In D66324#2336555, @lebedev.ri wrote:

In D66324#2336186, @phosek wrote:

I apologize for the late response, I somehow missed the earlier responses. We have successfully used this feature in Fuchsia and found it useful, but I agree that the issues raised need to be addressed. Unfortunately @paulkirth is no longer working on this project. I hope that someone from our team can take a look but it might take a few weeks. If you prefer, we could revert this change and then reland an improved version in the future?

I would very much prefer *NOT* not revert if someone is going to step up to work on these problems soon (within next 4 weeks?).

That being said, in light of that bug, my original doubts about the underlying data type (a novel MD_misexpect,
with structure different from MD_prof) have reappeared with double strength. I really think they should share underlying type.

I'll be posting a revert soon.

Landed in https://github.com/llvm/llvm-project/commit/d93287cac89fd50a105ac4a59c079884b8e53e49