xtensa-esp32-elf-gdb dependency on libpython2.7 (IDFGH-4510)

[KaeLL]

Title.
I'm building my code against IDF v4.1, and when I try to run espcoredump on it, it doesn't f work.
Running b015061 espcoredump on it yields this:

$ espcoredump.py info_corefile -t b64 -c coredump1 build/app_test.elf 
espcoredump.py v0.4-dev
Traceback (most recent call last):
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1572, in <module>
    main()
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1568, in main
    operation_func(args)
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1376, in info_corefile
    p = gdbmi_start(args.gdb, [rom_sym_cmd], core_filename, args.prog)
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1274, in gdbmi_start
    gdbmi_run_cmd_get_responses(res, "-data-list-register-values x pc", None, "console", multiple=True,
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1243, in gdbmi_run_cmd_get_responses
    more_responses = p.get_gdb_response(timeout_sec=0, raise_error_on_timeout=False)
  File "/tools/python_env/idf4.3_py3.8_env/lib/python3.8/site-packages/pygdbmi/gdbcontroller.py", line 269, in get_gdb_response
    self.verify_valid_gdb_subprocess()
  File "/tools/python_env/idf4.3_py3.8_env/lib/python3.8/site-packages/pygdbmi/gdbcontroller.py", line 175, in verify_valid_gdb_subprocess
    raise NoGdbProcessError(
pygdbmi.gdbcontroller.NoGdbProcessError: gdb process has already finished with return code: 127

And both v4.1 and v4.2 yield this:

$ espcoredump.py info_corefile -t b64 -c coredump1 build/app_test.elf 
espcoredump.py v0.4-dev
===============================================================
==================== ESP32 CORE DUMP START ====================
Traceback (most recent call last):
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1810, in <module>
    main()
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1805, in main
    operation_func(args)
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1633, in info_corefile
    p,task_name = gdbmi_freertos_get_task_name(p, extra_info[0])
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1532, in gdbmi_freertos_get_task_name
    p,res = gdbmi_data_evaluate_expression(p, "(char*)((TCB_t *)0x%x)->pcTaskName" % tcb_addr)
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1528, in gdbmi_data_evaluate_expression
    p = gdbmi_cmd_exec(p, handlers, "-data-evaluate-expression \"%s\"" % expr)
  File "/esp-idf/components/espcoredump/espcoredump.py", line 1482, in gdbmi_cmd_exec
    p.stdin.write(bytearray("%s\n" % gdbmi_cmd, encoding='utf-8'))
BrokenPipeError: [Errno 32] Broken pipe

There's nothing wrong with the coredump file, I even hexdump'ed it to make sure.

[igrr]

@KaeLL could you please mention, which OS are you using? Can you run xtensa-esp32-elf-gdb build/app_test.elf — does gdb also exit with an error?

In both cases you have posted, it seems that GDB process is returning with an error immediately.

[KaeLL]

@igrr

which OS are you using?

Kubuntu 20.04

Can you run xtensa-esp32-elf-gdb build/app_test.elf — does gdb also exit with an error?

$ xtensa-esp32-elf-gdb build/app_test.elf 
xtensa-esp32-elf-gdb: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

[igrr]

Perhaps it is the same issue as was reported in #5284? Could you try installing libpython2.7?

[dobairoland]

@KaeLL xtensa-esp32-elf-gdb --version doesn't throw the same error? (I'm think about how to check this)

[KaeLL]

@dobairoland it does.

[igrr]

Reopening as the linked docker related issue #5284 is now closed, and we don't have a fix for local installations on Linux yet.

[igrr]

To make this issue easier to find: linux builds of riscv32-esp-elf-gdb are affected by the same problem.

[KaeLL]

@igrr any ETA on this? Toolchain just got updated, and still no sign of a fix.

[igrr]

Hi @KaeLL, I'm sorry it's not fixed in this release yet. We have started working on separating GDB from the rest of the toolchain and fixing Python support (including Mac and Linux platforms) at the same time. I think we will get the initial version released before the end of year.

[mrklkrl]

yall got any more of them bugfixes?

[AxelLin]

I hit this issue on Ubuntu 21.10, running application on esp32c3 with v5.0-dev-1689-g66593bf140.

b'riscv32-esp-elf-gdb: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory\n'

[Lapshin]

Hi folks,

@mrklkrl, @AxelLin, @KaeLL good news: we have GDB with python support in pre-release state

You could get it from here https://github.com/espressif/binutils-gdb/releases/tag/esp-gdb-v11.1_20220318

P.s: It would be nice to hear your feedback on the new GDB release here :)

[KaeLL]

Awesome. Now, if any efforts could be directed towards fixing #6124, it would be perfect.

[KaeLL]

@Lapshin will this be backported to any of the release/v4.X branches? It's a fix after all, isn't it?

[Lapshin]

@KaeLL , sorry for the long delay. The backport for release/v4.4 will be available soon after the internal testing

[StarGate01]

@Lapshin Hey, any news of the backporting of the Python3 compatible GDP to 4.x ?

[Lapshin]

Hi @StarGate01 ,

esp-idf version 4.4.4 has esp-gdb-v11.2_20220823 which supports Python from version 3.6 to 3.10