Aha! I downloaded a version compiled with Python 3 support from here:
https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v10.3.1-2.2

And the gdb-frontend web page opens up!

I can confirm it uses python 3:

(gdb) python print(sys.version)
3.7.9 (default, Nov 11 2021, 14:33:28)
[Clang 10.0.0 (clang-1000.10.44.4)]

I'm getting other errors now (python errors) but at least its running. Thanks for the help!

from gdb-frontend.

Here is part of one library used in the project where I was getting a lot of errors:
https://github.com/4ms/stm32mp1-baremetal/tree/master/examples/audio_processor/lib/mdrivlib

Unfortunately I can't share the entire project, but this library contains many of the types that produces errors. I don't think you'll be able to see the errors unless you step through the code using actual hardware (that's when I saw them, not when the elf file is loaded).

I tried another project, but I get far fewer errors. I get a lot of "No symbol XXX in current context", which might just be from the variables being optimized out.
Here it is: https://github.com/4ms/tapographic-delay

Hope that helps. It's nice that you want to make this more useful for embedded projects, and I look forward to more releases/progress.

from gdb-frontend.

The only gdb executable I've been able to get working is the one from xpack (#37 (comment)). So I'm using the arm-none-eabi-gdb-py3 version from that.

I ran into compilation errors when trying to compile gcc v11.1 as you posted above. That's another issue in itself!
The xpack gdb version works with the macos-compat branch, but not with master.

From that gdb, the python version is:

(gdb) python print(sys.version)
3.7.9 (default, Nov 11 2021, 14:33:28)
[Clang 10.0.0 (clang-1000.10.44.4)]

What other environment information would you like to know?

from gdb-frontend.

Ah, one more thing, I realized I overlooked an error message earlier. When I connect to the tmux session, I see this:

GNU gdb (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.1.90.20201028-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/gdbfrontend/gdbfrontend.py", line 22, in <module>
    import settings
  File "/usr/local/lib/python3.9/site-packages/gdbfrontend/settings.py", line 14
    SET_CWD_TO_EXECUTABLE: bool
                         ^
SyntaxError: invalid syntax
Error while executing Python code.
(gdb)

Note, that if I use the non -py gdb executable, then I get the expected message Python scripting is not supported in this copy of GDB

So it appears that the python version that's part of arm-none-eabi-gdb doesn't support type hints.

from gdb-frontend.

Ah, one more thing, I realized I overlooked an error message earlier. When I connect to the tmux session, I see this:

GNU gdb (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.1.90.20201028-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/gdbfrontend/gdbfrontend.py", line 22, in <module>
    import settings
  File "/usr/local/lib/python3.9/site-packages/gdbfrontend/settings.py", line 14
    SET_CWD_TO_EXECUTABLE: bool
                         ^
SyntaxError: invalid syntax
Error while executing Python code.
(gdb)

Note, that if I use the non -py gdb executable, then I get the expected message Python scripting is not supported in this copy of GDB

I just added a check for does GDB have embedded Python: 4fe1f5c

This error means your GDB-embedded Python3 version is a little bit old, I will remove all typing things to support older Python3s.

Can you look for the output of this on GDB shell?

python print(sys.version)

We should find some quick solutions for different GDB distributions issues. I'm planning to add all kinds of GDB builds into the GDBFrontend releases.

from gdb-frontend.

Ah, yes I think this is the issue:

(gdb) python print(sys.version)
2.7.18 (default, Oct  2 2021, 04:20:39)
[GCC Apple LLVM 13.0.0 (clang-1300.0.29.1) [+internal-os, ptrauth-isa=deploymen

arm-none-eabi-gdb-py --config                                                                                                                                                                                                                       macos-compatibility
This GDB was configured as follows:
   configure --host=x86_64-apple-darwin10 --target=arm-none-eabi
...
             --with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
             --with-python-libdir=/System/Library/Frameworks/Python.framework/Versions/2.7/lib
...

Even the latest arm-none-eabi-gdb 10.3 was compiled with python 2.7.

So does gdbfrontend require python 3.x?

from gdb-frontend.

Even the latest arm-none-eabi-gdb 10.3 was compiled with python 2.7.

So does gdbfrontend require python 3.x?

Yes but GDB distributions are usually coming with Python3. Do you use a GDB from ARM?

from gdb-frontend.

Yes but GDB distributions are usually coming with Python3. Do you use a GDB from ARM?

Yes, from here:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

I see there's a later release (October 2021, I am using July 2021 version), so I'll see if that has python 3.

from gdb-frontend.

Yes but GDB distributions are usually coming with Python3. Do you use a GDB from ARM?

Yes, from here: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

I see there's a later release (October 2021, I am using July 2021 version), so I'll see if that has python 3.

Ok I'm looking for what can I do for this.

from gdb-frontend.

Aha! I downloaded a version compiled with Python 3 support from here: https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v10.3.1-2.2

And the gdb-frontend web page opens up!

I can confirm it uses python 3:

(gdb) python print(sys.version)
3.7.9 (default, Nov 11 2021, 14:33:28)
[Clang 10.0.0 (clang-1000.10.44.4)]

I'm getting other errors now (python errors) but at least its running. Thanks for the help!

Can you send errors?

from gdb-frontend.

First error happens when I set the target:

(gdb) target extended-remote 127.0.0.1:2331
Remote debugging using 127.0.0.1:2331
Python Exception <class 'AttributeError'> 'gdb.Inferior' object has no attribute 'inferior'

Next set of errors happens immediately afterwards. In my code, MMScreenBufferConf::FrameBufferT is an alias for std::array<unsigned short, 76800>. I never touched any UI elements (no watch variables, no windows).

(gdb) Traceback (most recent call last):
  File "/Users/design/src/gdb-frontend/api/debug.py", line 977, in serializable
    serializable["value"] = value.string()
gdb.error: Trying to read string with inappropriate type `std::array<unsigned short, 76800>'.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/design/src/gdb-frontend/api/debug.py", line 61, in _exec__mT
    output = callback(*args, **kwargs)
  File "/Users/design/src/gdb-frontend/api/debug.py", line 982, in serializable
    serializable["value"] = str(value)
gdb.error: value of type `MMScreenBufferConf::FrameBufferT' requires 153600 bytes, which is more than max-value-size

Traceback (most recent call last):
  File "/Users/design/src/gdb-frontend/api/debug.py", line 830, in getVariableByExpression
    value = gdb.parse_and_eval(expression)
gdb.error: No type "ST7789Init<(unsigned short)240, (unsigned short)320, (mdrivlib::ST77XX::InvertState)0>" within class or namespace "mdrivlib".

Traceback (most recent call last):
  File "/Users/design/src/gdb-frontend/api/debug.py", line 358, in getState
    variable = getVariableByExpression(symbol.name, no_error=False).serializable()
AttributeError: 'NoneType' object has no attribute 'serializable'

from gdb-frontend.

You can just ignore value errors. I will make it to handle and visualize all kinds of C++ objects but I have yet to do something for them. For now, I'm going to ignore this kind of value errors.

Important thing is do you having any issues to connecting to GDBServer?

I suggest you to run GDBFrontend on your remote machine and connect to it from your local machine. This will provide you a full-featured remote GDB debugging. That's one of the project's aims.

If you having issues with connecting to GDBServer, I will look for it.

One more thing, can you send your code? I will make it to handle and visualize them.

from gdb-frontend.

I've built GDB 11.1 with target arm-none-eabi .

(I will make all-in-one further releases and also I will make a documentation for building all kinds of GDB)

How to build GDB with a specific target

You may need some build-time dependencies

I had to install libgmp-dev package for Debian. If you have some missing build dependencies, configure script will say the missing library, just find it in your package management system and install.

Follow these steps

cd ~
wget https://ftp.gnu.org/gnu/gdb/gdb-11.1.tar.xz
tar zxvf gdb-11.1.tar.gz
mkdir gdb-11.1-build
cd gdb-11.1-build
../gdb-11.1/configure --with-python=/usr/bin/python3 --target=arm-none-eabi --enable-interwork --enable-multilib
make

Starting GDBFrontend with your GDB build

After build is successful, you should can run GDBFrontend like this:

gdbfrontend -g $(realpath ~/gdb-11.1-build/gdb/gdb) -G --data-directory=$(realpath ~/gdb-11.1-build/gdb/data-directory/)

It looks like this:

from gdb-frontend.

You can just ignore value errors. I will make it to handle and visualize all kinds of C++ objects but I have yet to do something for them. For now, I'm going to ignore this kind of value errors.

OK, it's understandable.

Important thing is do you having any issues to connecting to GDBServer?

Seems to be working at least at the basic level. It connects and I can set breakpoints and issue gdb commands from the embedded terminal. I can also view variables.
Since there are gdb commands that must be issued in order to connect to the GDBServer and then load the firmware .elf file, I'm used to using a .gdbinit file. I understand this is ignored by gdb-frontend. But if I pass -x /path/to/.gdbinit at the end of -G "ARGS" then, I get this error:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/design/src/gdb-frontend/gdbfrontend.py", line 35, in <module>
    gdb.execute("set non-stop off")
gdb.error: Cannot change this setting while the inferior is running.
Error while executing Python code.

So I have manually type "target extended-remote localhost:2331" and then "load" at the start of every session, which works. (My .gdbinit is exactly those two commands, with a newline separating them.)

I suggest you to run GDBFrontend on your remote machine and connect to it from your local machine. This will provide you a full-featured remote GDB debugging. That's one of the project's aims.

If you having issues with connecting to GDBServer, I will look for it.

I'm not sure I understand. I'm running JLinkGDBServer as my gdb server. This connects to the J-Link device via USB, which in turn is connected to my target microcontroller via SWD. Since it's an embedded device with a hardware user interface (knobs, buttons, screen, jacks), I need to be physically in front of the target device in order to debug.

One more thing, can you send your code? I will make it to handle and visualize them.

I can prepare something for you, to be shared privately.

from gdb-frontend.

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/design/src/gdb-frontend/gdbfrontend.py", line 35, in <module>
    gdb.execute("set non-stop off")
gdb.error: Cannot change this setting while the inferior is running.
Error while executing Python code.

Ah... another code blocks to avoid their error printings... Seems like non-stop mode is not available with target remote. I will solve these with next release.

I'm not sure I understand. I'm running JLinkGDBServer as my gdb server. This connects to the J-Link device via USB, which in turn is connected to my target microcontroller via SWD. Since it's an embedded device with a hardware user interface (knobs, buttons, screen, jacks), I need to be physically in front of the target device in order to debug.

I understand it. The only way is using JLinkGDBServer in this context.

Seems to be working at least at the basic level. It connects and I can set breakpoints and issue gdb commands from the embedded terminal. I can also view variables.

Nice... I will clear unnecessary warnings and solve the issues left with next release.

I can prepare something for you, to be shared privately.

It would be nice, I just need to see what kind of C++ types could not get handled and printing warnings.

from gdb-frontend.

@danngreen hello, any update on this?

from gdb-frontend.

Sooooo is the only problem is unnecessary warnings now?

from gdb-frontend.

Yes, just those warnings like I posted a few comments back: serializable["value"]... gdb.error: value of type... and gdb.error: No type ... etc.

I'm still on the macos-compatible branch, btw.

from gdb-frontend.

I'm still on the macos-compatible branch, btw.

There are so many updates :) I added the thing (realpath command) that exists in macos-compatibility to master branch.

You can use master branch since this commit: 1687e70

I think i may be solved unnecessary warnings issue too with newer versions. There are also so many performance enhancements and some thread-safety issues are fixed.

Can you try the latest revision on master?

from gdb-frontend.

Ah, ok. I just pulled master, checked it has the above commit. When I run gdbfrontend I get this immediately (no web browser opens):

  File "<string>", line 1, in <module>
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 116, in spawn_main
    exitcode = _main(fd, parent_sentinel)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 125, in _main
    prepare(preparation_data)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 236, in prepare
    _fixup_main_from_path(data['init_main_from_path'])
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 287, in _fixup_main_from_path
    main_content = runpy.run_path(main_path,
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 268, in run_path
    return _run_module_code(code, init_globals, run_name,
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 97, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/design/src/gdb-frontend/run.py", line 29, in <module>
    import api.globalvars
  File "/Users/design/src/gdb-frontend/api/globalvars.py", line 24, in <module>
    changed_registers = multiprocessing.Manager().dict()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 57, in Manager
    m.start()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/managers.py", line 554, in start
    self._process.start()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 284, in _Popen
    return Popen(process_obj)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 42, in _launch
    prep_data = spawn.get_preparation_data(process_obj._name)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 154, in get_preparation_data
    _check_not_importing_main()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 134, in _check_not_importing_main
    raise RuntimeError('''
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.
Traceback (most recent call last):
  File "/Users/design/src/gdb-frontend/./run.py", line 29, in <module>
    import api.globalvars
  File "/Users/design/src/gdb-frontend/api/globalvars.py", line 24, in <module>
    changed_registers = multiprocessing.Manager().dict()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 57, in Manager
    m.start()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/managers.py", line 558, in start
    self._address = reader.recv()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py", line 255, in recv
    buf = self._recv_bytes()
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py", line 419, in _recv_bytes
    buf = self._recv(4)
  File "/usr/local/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py", line 388, in _recv
    raise EOFError
EOFError

Should I re-open this? Or start a new issue?

from gdb-frontend.

Should I re-open this? Or start a new issue?

Oh, sure it would be better. Looks like we have some problems on MacOS.

from gdb-frontend.

@danngreen can you provide more information about your environment? (like Python version and installation)

from gdb-frontend.

Thank you for feedback. I will look at this.

from gdb-frontend.

Hii @danngreen,

Sorry for late action.. I think this issue is fixed now with e15f590. I tried on M1 MacBook (with Rosetta 2) it is working now. I'm not sure about if it is working properly on M1 with Rosetta 2; if you have Intel MacBook, i think it must work properly.

I will test debugging ARM and x86_64 applications on M1/Rosetta 2.

from gdb-frontend.

Must be fixed with v0.11.3-beta

from gdb-frontend.