Fix ranges autotest take 2 #505
Conversation
|
Interesting datapoint: the binutils maintainer mentioned they test against eu-readelf. I don't know how much of a drop-in replacement for readelf proper would that be. Elfutils doesn't have a Cygwin build, unfortunately. |
|
It's a readelf built from the latest head at the time of the PR, which is no longer current anyway, 'cause I did some more work on binutils since. If you'd rather hold on until a numbered release, that's fine. |
It's fine to cut the binary before a numbered release, but it should at least specify the git hash from which it's taken; I believe we've done this before. The reason is being able to reproduce the binary from source in case this is needed (on another platform, say) |
|
The hash is 84102ebc29a1ea531e7fe78bd841bfb2fe501dc2, now I have to figure out how to squish them... |
|
On a side note, I have a branch of pyelftools that autotests with the latest, latest readelf, too. I think I'll hold on to those changes until the binutils team drops a numbered release. It's not all descriptions, some API changes were needed, too. |
This was a while ago, but should probably still apply: https://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit |
|
I thought I've squashed them, but it still shows up as several commits. That's not the desired result, is it? |
The readelf in this one was built from the latest binutils' master.
The purpose of this was to remove the two file exception from the readelf..ranges test. In order to do that, I had to bring the rnglists section dump in line with what's in the latest GNU readelf master. The catch is that the rnglists section dump in GNU readelf was revised by me in https://sourceware.org/bugzilla/show_bug.cgi?id=30792 .
I'm not sure anymore what are we testing here.
It speaks to the viability of readelf as a reference implementation that the GNU binutils maintainers didn't get to it before I did.
The calling convention enum is just something I've noticed along the way and fixed.