-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
One step setup #43
Comments
The
The flash functionality of the gdb stub is not supported. IMO, it's a good idea to extend lldb to handle these use cases instead of giving up on it. |
I haven't had a chance to try LLD / LLDB yet - for now, do you have to build LLVM from scratch to install them? What version should we be using to be close to what Rust is using? Or can we get them by doing a full Rust build? Bobbin-CLI (https://github.com/bobbin-rs/bobbin-cli/) currently knows about many debuggers and flash loaders, and the documentation currently has pointers to download sites as well as some documentation about how to build and install them: https://github.com/bobbin-rs/bobbin-cli/blob/master/FIRMWARE.md There's also a "bobbin check" command that scans for all tools that it knows about and displays version information:
This could conceivably be extended to check for outdated versions and to add direct documentation links. Bobbin-CLI also has a database of USB Vendor / Product IDs that could be used I've considered adding Bobbin-CLI also supports dumping files onto USB MSD volumes, which covers many ST-Link and DAPLink debuggers, and it might not be too difficult to teach it enough of the GDB remote protocol to handle flashing to anything that exposes a GDB server (JLink, and Black Magic Probe). In the long run there is https://github.com/mbedmicro/FlashAlgo which is collecting flash algorithms for a wide variety of targets. So, it could conceivably have native flash loading support for a fairly broad range of boards and debuggers, limiting the OpenOCD dependency to people that need remote debugging or need to support devices that aren't covered. |
So is there interest in making an openocd crate so that it can be installed via cargo? I think this would be a requirement for useful |
Repackaging completely unrelated C applications in cargo seems wrong. The gcc crate doesn't package gcc... |
A few years ago, I built a simple tool to replace Bossa for my own use, to upload to the SAM3X8E. Here: https://github.com/hannobraun/embedded/tree/master/uploader I don't know how much is missing to make it useful, but I recall successfully using it to upload my program at the time. Maybe it can serve as a starting point or reference for your own efforts. |
@whitequark gcc isn't essential to the toolchain, and would require a dozen different crates for each architecture. Relying on distro package managers can be an option for Linux/established computer architectures. If we want a seamless experience for non-linux and archs like riscv, what do you suggest as an alternative? Rewriting openocd in rust is probably not a realistic goal till September |
@dvc94ch If you want a seamless experience? Rely on system package managers for Linux and OS X, and provide prebuilt Windows installers. Even if you did package openocd as a crate, it depends on, at least, MinGW, MSYS and libusb1 to build on Windows, and these dependencies ensure that it's not going to be installable as simple as |
I think OpenOCD is a well solved problem and I don't think we need to do
much there. What's more useful, I think, is helping people understand the
differences between the normal C development process for any given platform
and the 'normal' Rust development process. People could effectively then
apply those differences to almost any C example/tutorial they find for any
random board we've never even heard of.
I think what I'm saying is everything after the ELF is a platform problem
not a language problem and I think we should stick to language problems.
|
When Rust has LLD and LLDB integration, does anyone know whether Rust will build, ship, and install the standalone binaries also? And what about other utilities? I would hate to do all this work and still need the user to install the full GCC or LLVM toolchain just to get access to those utilities. Could they be packaged in a separate rustup |
objdump + size
They're from GNU Binutils, which is distinct to GCC and LLVM. I agree Rust
versions would be easier to ship, but I'm OK with depending upon binutils
as-is.
|
There are llvm-objdump and llvm-size since sometime late in 3.x cycle.
binutils are a really gross dependency to carry around. First, you get an entire second machine layer with its own independent bugs and deficiencies. There's no guarantee that the disassembler in binutils will know about all the same relocations as LLVM. (I've hit this.) Second, they're a pain in the ass to build on Windows as they require msys or cygwin. |
That's what rust-lang/rust#48125 does. A LLD binary will be shipped with the Rust toolchain; it will be somewhere in I don't know what's the LLDB plan with respect to PATH. |
There's a Rust tool that's basically a EDIT: Err, not Keystone; Capstone I think |
It's called cargo-sym but it doesn't seem like they are working on it anymore (no activity in the last 11 months). |
I really don't think we should use anything besides Ask me about that time I found out that OR1K assemblers in LLVM and binutils didn't match up, and then that LLVM and ld.bfd didn't agree on whether some DWARF relocation is absolute or relative... |
I tested Given that Once |
Can we get |
While you're at it, also include:
|
Oh, cool!
I totally agree that if there are LLVM equivalents then that's a much better approach, and an easier way to get all our architectures supported properly.
Oh man, that would really improve my workflow. |
Based on the discussion so far I have created two work items:
Help wanted! |
@therealprof had some success with lldb and stlink. [0] monitor and load can probably be implemented as python scripts. If someone gets it working with openocd I can probably port lldb to riscv. According to [1] it doesn't seem too involved to get a basic working debugger running and could probably be implemented in a week or two. (gdb keeps segfaulting on me, so I'd be interested in trying a different debugger)
[0] https://www.eggers-club.de/blog/2017/07/01/embedded-debugging-with-lldb-sure/ |
@dvc94ch The "problem" with lldb is its funny interpretation of the "standard" gdbserver protocol. It'll pretty much only work reliably with it's own counter implementation I toyed around with |
@therealprof mmh, are not the same people working on it that work on llvm? I got a small patch upstreamed, didn't seem that annoying. I guess it depends on who is actually in charge of the code you want to change? anyway that's a shame... |
Ooh, actually there seems to be movement on the gdbserver protocol support front since I last checked http://lists.llvm.org/pipermail/lldb-dev/2018-January/013078.html . @dvc94ch There's some overlap. But |
Nice, things are starting to move. Google contributes vFlash command support to lldb just a few days back, however it has been reverted due to virtual/physical address confusion. Otherwise I'd had done a quick check of whether the OpenOCD situation has improved. |
@dvc94ch You mentioned msp430 in your comment, did you mean riscv? |
Yes, I copy pasted it from the link I mentioned.
|
Those don't work on Windows do they? |
In theory they should. Will Most likely be a bit slow
whitequark <notifications@github.com> schrieb am Fr. 6. Apr. 2018 um 16:34:
… Those don't work on Windows do they?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD8E1SYBHMt3NWs54AK2SLiQBZKJfnzlks5tl30IgaJpZM4SNx4P>
.
|
Update on LLD: PR rust-embedded/cortex-m-rt#64 adds LLD support to cortex-m-rt. With that version you can build ARM Cortex-M programs without having to install arm-none-eabi-ld. Seems to work so far but will continue testing locally. |
I use Docker for Windows on Windows 10 all day long. It spins up a Hyper-V VM running a very minimal Linux OS (just enough to run a Docker container) at boot-up and the rest is transparent. |
How about macOS? |
It exists, but I haven't used it. Very similar idea I imagine. https://docs.docker.com/docker-for-mac/ Edit to add:
|
@whitequark What do you mean? Docker or run native? |
Do these prebuilt toolchains for macOS exist? |
@whitequark Yes, there're pre-built toolchains. Anything specific you're looking for? |
The toolchain Containers dont distinguish between host. On Linux they use
the native kernel, on Mac and Windows it's like jpster said via VM
whitequark <notifications@github.com> schrieb am Fr. 6. Apr. 2018 um 20:24:
… Do these prebuilt toolchains for macOS exist?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD8E1X3_MOBGhJQaQv7s5P7EcxPa07OPks5tl7L1gaJpZM4SNx4P>
.
|
@andre-richter Docker on Mac used to do Virtualbox VMs but now it runs stuff directly in a Hypervisor. |
I haven't actually used docker for anything Rust so far. So far all bits ran just fine natively. |
Yes but this is still a VM. It's not hosted by virtualbox anymore but macos
native framework.
Daniel Egger <notifications@github.com> schrieb am Fr. 6. Apr. 2018 um
20:28:
… @andre-richter <https://github.com/andre-richter> Docker on Mac used to
do Virtualbox VMs but now it runs stuff directly in a Hypervisor.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD8E1XmYArp0P_EvpFs8lvlPD4DPgoJoks5tl7PDgaJpZM4SNx4P>
.
|
Update from the dev-tools meeting regarding lldb: there has been ongoing work on improving Rust support in lldb and work there has been progressing nicely so they are now looking into shipping lldb as a rustup component. |
Awesome. Now if the gdb server protocol wouldn't suck so much that solutions were actually compatible... Nothing we can fix if I had to hazard a guess. |
Another update from dev-tools meeting regarding debuggers. It seems that the plan is to initially ship lldb on macOS and gdb on Linux as that would be faster to ship than to get lldb working perfectly everywhere and then ship that. Also this work is not part of the 2018 edition milestone so it's not high priority as other stuff but the initial shipping plan might get implemented in time for the 2018 edition. Still I think we could request they ship a gdb compiled with --enable-targets=all and that would still be a net win on Linux as one could use the same |
Weird. lldb runs perfectly on Linux, not sure what is missing here. I could understand if the notion was to use gdb on Linux because it provides more functionality but the same reasoning could be applied to ship gdb everywhere instead splitting between the two. 🤔 |
Just curious, now that https://reviews.llvm.org/D42145 has landed, has anyone tried using lldb for cortex-m recently? |
Is this happening? |
I'll ask. What's the recommended gdb version for debugging RISCV binaries? HEAD, or does the latest stable release have good RISCV support? |
binutils has been upstream for a while. Latest stable should be ok. |
Closing this as part of the 2024 triage. Today, it is possible to obtain binutils via rustup and using the If you think this was closed incorrectly, please leave a comment and we can revisit this decision in the next weekly WG meeting on Matrix. |
Embedded development involves cross compilation and remote debugging; the Rust toolchain doesn't
provide all the tools so you have to install external ones like: a cross linker (e.g.
arm-none-eabi-ld
), a cross debugger (e.g.arm-none-eabi-gdb
), some tool to communicate with theremote target (e.g.
OpenOCD
), etc.It would be great if the user didn't have to figure out where to get all those tools and install
them manually.
There are a few upcoming changes that might affect this situation.
lld
binary will be shipped with the Rust toolchain. cf. PR rust: Import LLD for linking wasm objects rust-lang/rust#48125lld
is a multi-arch linker and it can be used to link ARM Cortex-M binaries so once this is inplace user won't need to install
arm-none-eabi-ld
.I don't think
lld
supports any of the other embedded targets (MSP430, AVR or RISCV) thoughlldb
binary will shipped with the Rust toolchain. cf. issue Ship a custom LLDB with Rust support rust-lang/rust#48168lldb
is a multi-arch debugger. I personally could never get it to work with OpenOCD; I never foundan equivalent to the
monitor
andload
commands which are used to flash the binary into theremote target.
lldb
can debug ARM Cortex-M programs just fine; I have used it debug a emulated ARMCortex-M microcontroller (QEMU).
Maybe someone had more luck with it and can share their experience?
One way to address this setup problem could be to provide a installer (script) like
https://rustup.rs/ does but for each target architecture.
cc @jcsoo
The text was updated successfully, but these errors were encountered: