eliben / pyelftools

Parsing ELF and DWARF in Python

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Release 0.30 (was: Consider a new release?)

pombredanne opened this issue · comments

It has been almost a year since 0.29 and there are great stuff in the latest head.... may be it is time to cut a release!
Thanks!

I went over the commit log and I don't see lots of very major changes. Anything in particular there that you require?

No major changes but bug fixes indeed! :]
Your call. No rush since there no no API changes that I can see.

Some bugs are fixed for sure:
I have this in 0.29:

self = <elftools.dwarf.abbrevtable.AbbrevTable object at 0x7fc73cd9fbe0>, code = 7285

    def get_abbrev(self, code):
        """ Get the AbbrevDecl for a given code. Raise KeyError if no
            declaration for this code exists.
        """
>       return self._abbrev_map[code]
E       KeyError: 7285

venv/lib/python3.8/site-packages/elftools/dwarf/abbrevtable.py:36: KeyError

using this https://github.com/eliben/pyelftools/blob/master/test/testfiles_for_readelf/cuv5_x86-64_gcc.so.elf

but not with the latest head
(this is using dwarfdump for example)

Renaming this issue. I'm OK with releasing the next version, but we'll need to see what is pending to get in.

It would be great to have the LoongArch support from 2059475 in a release.

See https://bugs.gentoo.org/911484 .

Thanks for the followup for the bug, @floppym! I've since checked the existing logic and found they needed some fixes, and filed #483 for it. We probably want that included too if we're aiming for proper LoongArch support.

I'm applying that PR locally for testing and will post my results on the PR shortly after.

@sevaa thoughts about making this release soon? I think we got almost all the pending stuff in.

@xen0n please act on the comments in #483 if you want this in 0.30; otherwise it will just make it into the next release - no big deal. FWIW I recommend people to use pyelftools hot and fresh off the master branch anyhow.

I'd prefer to get #483 in, and also I'd like to take a stab at bringing back the ranges test against the master head of binutils. I'll bump to a numbered release once there is one.

Quick update re: rangelists. There was no activity on that bug for a week, so I went into the sources. Remember the rant re: overlapping rangelists that I've left in pyelftools comments? Readelf has it both ways. For v4 sections, it goes by known rangelist offsets (aka "for utility"). For v5 sections, it goes by offset tables in rnglist-CU headers, aka "for fidelity", and does so incorrectly.

I'd take a stab at fixing this myself in readelf, but I really want the maintainers to confirm that inconsistency in approach is intentional or at least to be tolerated for now.

Aren't we done with the desired scope for 3.0? I still have on my plate two cases of shorted out autotests that I would prefer to address, but that's not functionality and can wait until after the release.

I've tagged v0.30 and pushed it to PyPI.

@pombredanne and @sevaa please install the new version and let me know if you see any issues.

My tests pass.

Found some minor unrelated crud though, like some missing vendor attribute codes. Oh well.

My tests pass.

Found some minor unrelated crud though, like some missing vendor attribute codes. Oh well.

Thanks for testing. Send a PR for the other stuff - I don't think that missing a release is a big deal. I recommend people to use the master version anyhow - with the testing we do on every commit it's usually more stable / less buggy than released versions.

@eliben Thank you ++. You rock 🎸