[0/3] Parse <elf.h> in the glibcelf Python module

Message ID cover.1662385087.git.fweimer@redhat.com
Headers
Series Parse <elf.h> in the glibcelf Python module |

Message

Florian Weimer Sept. 5, 2022, 1:44 p.m. UTC
  This simplifies maintenance (backporting in particular), adds additional
consistency checks (for otherwise-unused constants in <elf.h>), and
should help with compatibility with earlier Python versions.

If we want to use glibcelf more extensively in the test suite, I think
we need to optimize the parser performance a bit.  The prefix matching
is currently rather inefficient.  It should not be too hard to change
that.

Tested on i686-linux-gnu, x86-64-linux-gnu (the latter with Python 3.6
and Python 3.10).  Build with build-many-glibcs.py.

Thanks,
Florian

Florian Weimer (3):
  scripts: Extract glibcpp.py from check-obsolete-constructs.py
  scripts: Enhance glibcpp to do basic macro processing
  elf: Extract glibcelf constants from <elf.h>

 elf/tst-glibcelf.py                  |   79 +-
 scripts/check-obsolete-constructs.py |  189 +----
 scripts/glibcelf.py                  | 1013 ++++++++++----------------
 scripts/glibcpp.py                   |  529 ++++++++++++++
 support/Makefile                     |   10 +-
 support/tst-glibcpp.py               |  217 ++++++
 6 files changed, 1194 insertions(+), 843 deletions(-)
 create mode 100644 scripts/glibcpp.py
 create mode 100644 support/tst-glibcpp.py


base-commit: 29eb7961197bee68470730aecfdda4d0e206812e
  

Comments

Florian Weimer Sept. 5, 2022, 2:36 p.m. UTC | #1
* Florian Weimer via Libc-alpha:

> This simplifies maintenance (backporting in particular), adds additional
> consistency checks (for otherwise-unused constants in <elf.h>), and
> should help with compatibility with earlier Python versions.
>
> If we want to use glibcelf more extensively in the test suite, I think
> we need to optimize the parser performance a bit.  The prefix matching
> is currently rather inefficient.  It should not be too hard to change
> that.

Actually, profiling suggests it's the C tokenizer. 8-/ That's going to
be more difficult to optimize.  It's still not too bad for now.

Thanks,
Florian