gdb-dashboard
sdk-ng
Our great sponsors
gdb-dashboard | sdk-ng | |
---|---|---|
19 | 4 | |
10,622 | 159 | |
- | 5.7% | |
4.4 | 8.0 | |
about 2 months ago | 4 days ago | |
Python | C | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gdb-dashboard
- Cyrus-and/GDB-dashboard: Modular visual interface for GDB in Python
-
Everything You Never Wanted to Know About CMake (Redux)
Disclaimer: I'm making a competing build system.
I won't tell you specific build systems, but I will tell you what to look for.
Look for power. Unlimited power. [1]
Usually, this means a few things:
1. The build system uses a general-purpose language, even if the language needs features to be added.
2. The build system does not reduce the power of the general-purpose language. For example, say it starts with Python but prohibits recursion. In that case, you know it is not unlimited power. Looking at you, Starlark.
3. The build can be dynamically changed, i.e., the build is not statically determined before it even begins.
4. Each task has unlimited power. This means that the task can use a general-purpose language, not just run external processes.
5. And there has to be some thought put it in user experience.
Why are these important? Well, let's look at why with CMake, which fails all of them.
For #1, CMake's language started as a limited language for enumerating lists. (Hence, CMakeLists.txt is the file name.) And yet, it's grown to be as general-purpose as possible. Why? Because when you need an if statement, nothing else will do, and when you need a loop, nothing else will do.
And that brings us to #2: if CMake's language started limited, are there still places where it's limited? I argue yes, and I point to the article where it says that your couldn't dynamically call functions until recently. There are probably other places.
For #3, CMake's whole model precludes it. CMake generates the build upfront then expects another build system to actually execute it. There is no changing the build without regenerating it. (And even then, CMake did a poor job until the addition of `--fresh`.) A fully dynamic build should be able to add targets and make others targets depend on those new targets dynamically, among other things.
For #4, obviously CMake limits what tasks can do because Ninja and Make limit tasks to running commands.
As another example, to implement a LaTeX target, you technically need a while loop to iterate until a fixed point. To do that with Make and Ninja, you have to jump through hoops or use an external script that may not work on all platforms.
CMake obviously fails #5, and to see how much other build systems fail it, just look for comments pouring hate on those build systems. CMake fails the most, but I haven't seen one that passes yet.
As an example, CMake barely got a debugger. Wow! Cool! It's been 20 years! My build system will have a debugger in public release #2 (one after the MVP) that will be capable of outputting to multiple TTY's like gdb-dashboard. [2] They should have had this years ago!
Should other comments suggest specific build systems, like the one that suggested Bazel, judge them by this list. Some will be better than others. None will pass everything, IMO, which is why I'm making my own.
[1]: https://youtube.com/watch?v=Sg14jNbBb-8
[2]: https://github.com/cyrus-and/gdb-dashboard
-
VSCode -> VIM, but how do I accomplish the other IDE tasks?
To debug, termdebug is built in to vim and supports a front end to gdb. In combination with gdb-dashboard this gives a reasonably good debugging experience
-
Are there any cpu emulators that could help me learn i386 assembly?
https://github.com/cyrus-and/gdb-dashboard, https://github.com/cyrus-and/gdb-dashboard/wiki
-
Usage of GDB over command line
You can use the Python API to GDB to get really fancy TUIs like this: https://github.com/cyrus-and/gdb-dashboard
-
Debugging with GDB
Try GDB Dashboard, it makes gdb much easier to use:
https://github.com/cyrus-and/gdb-dashboard
There's also Voltron which works with both gdb and lldb (amongst others):
https://github.com/snare/voltron
I can't believe no one has mentioned `gdb-dashboard` [1] yet! I use it extensively. [2]
Beyond that, I have recently learned how to write custom pretty printers for GDB. This saves a lot of screen space. I should probably update [2] soon with those new techniques.
GDB is powerful, useful, and after getting my start in IDE debuggers, including Visual Studio, I struggle whenever I have to go back.
[1]: https://github.com/cyrus-and/gdb-dashboard
[2]: https://gavinhoward.com/2020/12/my-development-environment-a...
- Gdb-dashboard: a better TUI for gdb
-
How do I "replicate" an IDE like the Keil uVision or the TI CCS using Visual Studio Code?
Debugging: Learn gdb. You can use it for assembly. You can use it for C on a MCU. You can use it for Go on a Linux system. It’s ubiquitous, versatile, and worth understanding. You can pretty-print the output with something like this to help you out at first. There are 2 things you need, however: on chip debugger and a debug probe (though you don’t need an expensive one). Effectively, you talk to GDB, GDB talks to the server exposed by OCD, OCD knows the debug probe protocol, and the debug probe can use the MCU debug peripheral via SWD or JTAG to get those details.
-
Using gdb to be productive
I use gdb because I'm usually in the terminal. I don't think terminal it's any faster though. This is a nice addition to boring old terminal gdb.
sdk-ng
-
Need help getting Zephyr RTOS native_posix target working from an x86_64 host
# Basic configuration for Zephyr development. { pkgs ? import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/refs/tags/23.05.tar.gz") { } }: let pp = pkgs.python3.pkgs; imgtool = pp.buildPythonPackage rec { version = "1.10.0"; pname = "imgtool"; src = pp.fetchPypi { inherit pname version; sha256 = "sha256-A7NOdZNKw9lufEK2vK8Rzq9PRT98bybBfXJr0YMQS0A="; }; propagatedBuildInputs = with pp; [ cbor2 click intelhex cryptography ]; doCheck = false; pythonImportsCheck = [ "imgtool" ]; }; python-packages = pkgs.python3.withPackages (p: with p; [ autopep8 pyelftools pyyaml pykwalify canopen packaging progress psutil anytree intelhex west imgtool cryptography intelhex click cbor2 # For mcuboot CI toml # For twister tabulate ply # For TFM pyasn1 graphviz jinja2 requests beautifulsoup4 # These are here because pip stupidly keeps trying to install # these in /nix/store. wcwidth sortedcontainers ]); # Build the Zephyr SDK as a nix package. new-zephyr-sdk-pkg = { stdenv , fetchurl , which , python38 , wget , file , cmake , libusb , autoPatchelfHook }: let version = "0.15.0"; arch = "arm"; sdk = fetchurl { url = "https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v${version}/zephyr-sdk-${version}_linux-x86_64_minimal.tar.gz"; hash = "sha256-dn+7HVBtvDs2EyXSLMb12Q+Q26+x6HYyPP69QdLKka8="; }; armToolchain = fetchurl { url = "https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v${version}/toolchain_linux-x86_64_arm-zephyr-eabi.tar.gz"; hash = "sha256-B7YIZEyuqE+XNI7IWnN6WiC1k9UdFEt4YN4Yr7Vn3Po="; }; in stdenv.mkDerivation { name = "zephyr-sdk"; inherit version; srcs = [ sdk armToolchain ]; srcRoot = "."; nativeBuildInputs = [ which wget file python38 autoPatchelfHook cmake libusb ]; phases = [ "installPhase" "fixupPhase" ]; installPhase = '' runHook preInstall echo out=$out mkdir -p $out set $srcs tar -xf $1 -C $out --strip-components=1 tar -xf $2 -C $out (cd $out; bash ./setup.sh -h) rm $out/zephyr-sdk-x86_64-hosttools-standalone-0.9.sh runHook postInstall ''; }; zephyr-sdk = pkgs.callPackage new-zephyr-sdk-pkg { }; packages = with pkgs; [ # Tools for building the languages we are using llvmPackages_16.clang-unwrapped # Newer than base clang gnat zig zls rustup glibc_multi # Dependencies of the Zephyr build system. (python-packages) cmake ninja gperf python3 ccache dtc gmp.dev zephyr-sdk ]; in pkgs.mkShell { nativeBuildInputs = packages; # For Zephyr work, we need to initialize some environment variables, # and then invoke the zephyr setup script. shellHook = '' export ZEPHYR_SDK_INSTALL_DIR=${zephyr-sdk} export PATH=$PATH:${zephyr-sdk}/arm-zephyr-eabi/bin export VIA_WORKSPACE_PATH="$(realpath ./workspace/)" source ./workspace/zephyr/zephyr-env.sh ''; }
-
Dev environment
I just get the cross compile tools from ARM : https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads ... or zephyr : https://github.com/zephyrproject-rtos/sdk-ng/releases
-
How do I "replicate" an IDE like the Keil uVision or the TI CCS using Visual Studio Code?
There are free gcc based cross tools (compilers, debuggers, emulators) for a lot of MCUs (ARM, MIPS, riscv, etc).
-
When you talk about compilers does each processor have its own compiler for it? Say I am compiling a code a C code for the ESP32 and compiling a C code for the Arduino, will the compiler will be with respect to the C standard being used ( e.g. C89, C11 ) or is the compiler unique to the processor?
Eg: Zephyr OS can use the https://github.com/zephyrproject-rtos/sdk-ng toolchain, which is built for arm, riscv, mips targets.
What are some alternatives?
gef - GEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs & reverse engineers on Linux
C++ REST SDK - The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.
lldb-mi - LLDB's machine interface driver
openapi-generator - OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
pdb-tutorial - A simple tutorial about effectively using pdb
Abstract - neovim as an IDE
nvim-gdb - Neovim thin wrapper for GDB, LLDB, PDB/PDB++ and BashDB
pwndbg - Exploit Development and Reverse Engineering with GDB Made Easy
gdb-frontend - ☕ GDBFrontend is an easy, flexible and extensible gui debugger. Try it on https://debugme.dev
syntax-highlighting - A fork of Tiago Barroso's Syntax Highlighting add-on with support for Anki 2.1
gdb-dashboard-svdregisters - Tool and module for adding any register to gdbinit from svd-file
voltron - A hacky debugger UI for hackers