-
-
Notifications
You must be signed in to change notification settings - Fork 45
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
Explore binary overhead in mixed Rust + C/C++ projects #101
Comments
I'm excited to hear that you're taking a crack at using In any case, to answer your question: there are some potentially non-obvious tricks that you can use to trim the binary down even more:
Let me know if that helps the situation somewhat. Also, I'm not sure if you know about this, but |
Hey, I was wondering if you ever had a chance to explore some of these ideas? |
Hi Thank you |
When you say "the generics", can you elaborate a bit? Most of my claims regarding gdbstub's small-size are based on the notion that the optimizing compiler is smart enough to eliminate dead code of all the unused protocol extensions. In my experience, this has been the case on x86/64, but it might be the case that other platforms don't have the same kind of optimizations. If that's the case, I would be very interested in digging into that. |
Hi Edit platformConfig.cmake to point to a valid arm cross compiler (arm-none-eabi-) The project generates a .map file which can be analyzed to see what file/symbol is taking a lot of room gdbstub::stub::core_impl::monitor_cmd::_$LT$impl$u20$gdbstub..stub..core_impl..GdbStubImpl$LT$T$C$C$GT$$GT$::handle_monitor_cmd::h45fe3ef669a69925 468 There is a lot of smallish functions that look like generics ans when summed up take a lot of space |
Sure, I don't mind waiting a bit and circling back. In the meantime though, can you confirm that the repo you linked is the most up-to-date version of the code? That repo contains a lot of code that doesn't follow those suggestions I mentioned earlier... As for what might be happening here, a few things spring to mind:
|
Hi, For the last part, that's probably a big chunk of the issue. That may be as simple as that. I'll have to make LTO work and see what happens |
Well, let me know when you push those changes somewhere I can take a look at them myself, and then we can continue this exploration :) |
Hi (rust/llvm LTO does not seem to work with gcc LTO) |
Ah, that's great to hear! That makes a lot of sense. Should I close this issue, or do you think this is something we should document somewhere (e.g: in the README)? |
Please close it. Indeed maybe a pointer in the doc would be helpful for others. |
Hi
First of all thank you for this nice project.
I was looking at it with the goal of embedding it on a small arm or riscv board and talk to it over usb/cdc.
So far it looked like a perfect match
But then i tried to build the no_std example on top of my project baseline, that is a mix of C++ and rust. The base project is ~ 20 kB binary size.
It built find, except it consumed a metric ton of flash (i guess this is all relative :) ) .
With a lazy setup i was around 600 kB, using all the tricks i now it went down to ~ 200 kB.
I've looked into the why, ~ 80 kB or so is gdbstub/_arch itself, ~ 120 kB is pulling dependencies from core, fmt,...
In the example, calling gdb.incoming_data(&mut target, byte) is enough for the final executable to jump from 20k to 220 kB
(binary size), as the code is no longer tagged as not used and is not removed.
So a couple of questions :
Thank you again
The text was updated successfully, but these errors were encountered: