Comments (25)
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 messagePython 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.
Related Issues (20)
- Alert!: Unable to connect to remote host. HOT 22
- sorting files in folder in the sources aids the navigation HOT 3
- GDB executable not found due to $PWD is modified by gdbfrontend HOT 6
- a
- Not support risc-v HOT 3
- How to debug a GDB Python extension (pdb)? HOT 1
- How to debug apps get inputs from TTY? HOT 4
- gdb main thread is bloocking ... HOT 7
- FeatReq: Close windows in right sidebar HOT 5
- Update Ace editor HOT 3
- building gdb on arch failed HOT 2
- Accessing debugger interface from another machine (Access is denied) HOT 2
- Problems encountered during trying out gdb-frontend HOT 2
- macOS Thread no longer exists HOT 7
- RFE: step OUT HOT 1
- Evaluating pointers as arrays HOT 1
- Error message when running on WSL2 Linux HOT 2
- view variable value inline HOT 2
- support for rr debugger HOT 3
- Cannot use --args for gdb HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gdb-frontend.