GeezerVison

Can you call readelf -e <binary_path> and grep .note.bolt_info? Checking headers is efficient and robust.

I also think it will be the best way to handle this issue. But I am not sure it will be okay to call external binary for this. I may need to get opinions from @vstinner and @erlend-aasland WDYT?

Why not checking sysconfig? This check looks slow and not reliable.

Why not checking sysconfig? This check looks slow and not reliable.

Do you have any recommendation points? CFLAG does not guarantee the build is BOLTed.

Maybe test:

'--enable-bolt' in sysconfig.get_config_var('CONFIG_ARGS')

Only put the code in test_gdb if you're worried that the the test is not reliable. And add a comment to explain it.

Well then there is no way to display the optimization information but okay got it.

You cannot expect "readelf" to be available, it would be a new dependency. I dislike looking for a string in a binary without parsing the ELF binary.

We call external binaries in test.support to determine macOS features, so there is precedent for doing that sort of thing; is readelf a standalone package, or is it part of the compiler toolchain?

; is readelf a standalone package, or is it part of the compiler toolchain?

AFAIK, it's part of binutils: https://sourceware.org/binutils/docs/binutils/readelf.html

AFAIK, it's part of binutils: https://sourceware.org/binutils/docs/binutils/readelf.html

Thanks. binutils is preinstalled on the Ubuntu runners GitHub provides, so there is no more dependencies for the CI there. Also, anyone who wants to build their own CPython probably already did apt install build-essential, which includes binutils. Looks to me like there are no more deps introduced. What about macOS?

This comment only says what the code does, but not why. Could you rewrite it to state why this is happening? I can easily see by the code that we always return false if we're on WASI; there is no need to manifest that info into a comment ;)