|
I realize that in school they taught you to use print statements to trace your code. that’s amateur level poo poo. if you’re being paid to write code, it’s time to start using tools like a professional. learn how to use a debugger. I’ve debugged all kinds of code, from low level boot loaders whose only io was blinking a single LED to great big multithreaded monsters that spew gigs of logs. and I was able to use a debugger on all of them to make my life better and so can you. when you start a project, the first thing you do after writing the boilerplate main function is get the debugger working. for most of you writing normal programs, it’s as easy as running the debugger that comes with your tool chain, zero effort. remember to add the debug symbols flags to your build. if you’re working with an embedded target or simulator or FPGA or gpu or whatever, it will take more work. whether it’s a debug server or jtag or ICE or some other nonsense, get that poo poo up and running before writing any more code. set up core dumps. get stack traces from crashes. if you are asked to join a project, ask them how they debug. if they say printf tell them to get hosed. or fix that. whichever. but if they don’t want to fix it, definitely the former. if the language doesn’t support a debugger, it is a bad language and you should not use it. if your board doesn’t have a debug port, send it back to the idiots that made it and tell them it’s broken. it’s time to put on our big boy pants and start acting like professionals.
|
# ? Oct 19, 2019 19:05 |
|
|
# ? Jun 1, 2024 04:29 |
|
sir this is a wework
|
# ? Oct 19, 2019 19:28 |
|
what is code
|
# ? Oct 19, 2019 20:20 |
|
The Management posted:I realize that in school they taught you to use print statements to trace your code. that’s amateur level poo poo. if you’re being paid to write code, it’s time to start using tools like a professional. learn how to use a debugger. I’ve debugged all kinds of code, from low level boot loaders whose only io was blinking a single LED to great big multithreaded monsters that spew gigs of logs. and I was able to use a debugger on all of them to make my life better and so can you. lol
|
# ? Oct 19, 2019 20:35 |
|
debuggers are just interactive printf
|
# ? Oct 19, 2019 20:45 |
|
tell me how to use remote gdb/lldb with clion and rust please op. my target has such little memory that the the debug symbol file can't even fit on the device so i have printlns with a 20 min bitbake build it loving suuuuuuucks
|
# ? Oct 19, 2019 20:56 |
|
ill give you my printf when you pry it from my cold, segfaulted hands
|
# ? Oct 19, 2019 21:05 |
|
every time I connect symbolication takes 5-10 minutes and a bunch of symbols are still missing anyway. and hopefully you're on the right thread because the process has 70+
|
# ? Oct 19, 2019 21:37 |
|
gonadic io posted:tell me how to use remote gdb/lldb with clion and rust please op. my target has such little memory that the the debug symbol file can't even fit on the device so i have printlns with a 20 min bitbake build it loving suuuuuuucks why would you put the symbols on the device? symbols are for your debugger, they should stay on the host. load the unstripped image in the debugger when you connect.
|
# ? Oct 19, 2019 22:14 |
|
DuckConference posted:every time I connect symbolication takes 5-10 minutes are you pulling symbols from the execution image or from the debug binary? most compilers are pretty good at generating efficient lookup tables for symbols in debug data. they tend to get huge though. also you’re probably symbolizing a lot of libraries, possibly fetching their debug data from a remote machine if your environment is complex enough. have you tried caching them locally?
|
# ? Oct 19, 2019 22:18 |
|
Jonny 290 posted:sir this is a wework
|
# ? Oct 19, 2019 22:23 |
|
gonadic io posted:tell me how to use remote gdb/lldb with clion and rust please op. my target has such little memory that the the debug symbol file can't even fit on the device so i have printlns with a 20 min bitbake build it loving suuuuuuucks also implementing gdb protocol over uart is pretty easy if you just want to write your own stub. the rust part I can’t help you with. despite what people keep saying, it’s unsuitable for systems programming.
|
# ? Oct 19, 2019 22:31 |
|
The Management posted:also implementing gdb protocol over uart is pretty easy if you just want to write your own stub. I think the onus is on you to prove that last bit
|
# ? Oct 19, 2019 22:35 |
|
Using a debugger is computer vivisection
|
# ? Oct 20, 2019 01:20 |
|
The Management posted:are you pulling symbols from the execution image or from the debug binary? most compilers are pretty good at generating efficient lookup tables for symbols in debug data. they tend to get huge though. also you’re probably symbolizing a lot of libraries, possibly fetching their debug data from a remote machine if your environment is complex enough. have you tried caching them locally? nothing remote, but the binary in question is like 60MB when fully stripped (and doesn't fit on device if not)
|
# ? Oct 20, 2019 02:39 |
|
i learned to use gdb in school, op
|
# ? Oct 20, 2019 02:40 |
|
slam in jtag, start t32. system.attach break blow deadlines. external watchdog trips. debugger aborted, cpu at exception vector. system safes. ah yes, in circuit debugging. lemme just apply this .diff to disable safety critical code and do a 30 minute rebuild. that way no production image ever sees a debugger. I hate the few tools I have. Maybe I should have bought a trace tool and not just a debugger. Or maybe debugging rtos stuff is impossible.
|
# ? Oct 20, 2019 03:14 |
|
my boss isn't selling debuggers op
|
# ? Oct 20, 2019 03:27 |
|
i use sprintf to generate a variable dump and then have the system e-mail it to me. great for those mystery bugs that only happen in production.
|
# ? Oct 20, 2019 03:35 |
|
The Management posted:to great big multithreaded monsters that spew gigs of logs. Logs generated by printf?
|
# ? Oct 20, 2019 03:48 |
|
horse_ebookmarklet posted:Or maybe debugging rtos stuff is impossible. it’s very possible. you will usually need to teach your debugger about the thread model, and if you have a really good one it will know about your interrupt context. if your watchdog tripped, you should halt and look at the state of all the threads. check the scheduler context for them, who is blocked on what, who is doing what, figure out why the deadline is blown instead of guessing. why does your build take 30 minutes? is your build system written in python?
|
# ? Oct 20, 2019 04:26 |
|
CRIP EATIN BREAD posted:i learned to use gdb in school, op good start.
|
# ? Oct 20, 2019 04:32 |
|
i write things that end up in production, op, so logging is a must
|
# ? Oct 20, 2019 05:05 |
|
i don’t get why you don’t just write the code well in the first place
|
# ? Oct 20, 2019 06:15 |
|
echinopsis posted:i don’t get why you don’t just write the code well in the first place You use the debugger to show other people how sick your code is.
|
# ? Oct 20, 2019 06:23 |
|
badass
|
# ? Oct 20, 2019 09:22 |
|
The Management posted:. Mine does, it's yocto. Full kernel build takes a few hours
|
# ? Oct 20, 2019 09:38 |
|
the solution seems real simple to me. just program the computer to be faster
|
# ? Oct 20, 2019 09:52 |
|
I've seen webapps produce gigabytes worth of logs everyday, because the webapp was full of debug print statements. Not because it was receiving a lot of traffic.
|
# ? Oct 20, 2019 10:12 |
|
In my previous job I couldn't attach a debugger because a) the SoC didn't have enough free pins for an UART unless I disabled some important functionality, and b), parts of the board could potentially literally catastrophically fail if the execution stopped in an importune moment. I didn't have access to printfs either though, had to do with debug registers.
|
# ? Oct 20, 2019 11:49 |
|
and by "enough" I mean any
|
# ? Oct 20, 2019 11:55 |
|
current employer doesn't want us writing log files. "Everything must go through AWS CloudWatch, so says the SOP!" cloudwatch has yet to be configured and probably won't be for some time as the team responsible for anything aws is on fire
|
# ? Oct 20, 2019 12:28 |
|
it sounds like computers are bad
|
# ? Oct 20, 2019 14:33 |
|
tell me how to live step-debug on 15 year old win CE 6 r3 devices, op
|
# ? Oct 20, 2019 15:04 |
|
just reimplement the system whenever there's a bug, OP
|
# ? Oct 20, 2019 15:09 |
|
Gazpacho posted:my boss isn't selling debuggers op another day at the printf() factory
|
# ? Oct 20, 2019 15:37 |
|
Private Speech posted:In my previous job I couldn't attach a debugger because a) the SoC didn't have enough free pins for an UART unless I disabled some important functionality, and b), parts of the board could potentially literally catastrophically fail if the execution stopped in an importune moment. sounds like the hardware designers really hosed up here. they picked a bad chip with a bad configuration. I suggest you return the board to whoever made it and tell them to fix their lovely design. debugging is not an option, it’s a requirement for software to work correctly. Ciaphas posted:tell me how to live step-debug on 15 year old win CE 6 r3 devices, op install visual studio 6 or whatever it was at the time, get MTP going over a usb connection, live step debug. visual studio had an amazing debugger.
|
# ? Oct 20, 2019 15:40 |
|
https://www.youtube.com/watch?v=yqDVtB-6jDE&hd=1
|
# ? Oct 20, 2019 15:42 |
|
I could have made a career out of telling hardware and ops people that their poo poo is broken because you can’t debug it. it amazes me that idiots still make boards that have no hard debug interfaces, or that significantly reduce functionality to enable debug. at Apple, the low level software team signs off on schematics before they are approved. you can bet nothing gets signed off if it’s not debuggable. tell your boss and your PMs and your hardware folks that you will not be accepting undebuggable boards and you expect to sign off on designs and chip selections before they make the boards. so say we all.
|
# ? Oct 20, 2019 15:49 |
|
|
# ? Jun 1, 2024 04:29 |
|
The Management posted:install visual studio 6 or whatever it was at the time, get MTP going over a usb connection, live step debug. visual studio had an amazing debugger. realpost: tldr, but suffice to say MTP is seemingly impossible to get working, Hardware took the UART out of the "newest" revision, whatever module provides ActiveSync doesn't work reliably for debugging via IP, and even if by some miracle it DOES all work, the machine is too gutless to run a debug executable at anything other than unreasonable treacle-like speeds. we're on vs2005 for that so when it does work it at least works well, but yeesh what a fuckin farce to get there and god help me if what i need to test is buried behind slow-running actions it's pretty crap but at least it's being greenfielded away to unix boxes in the next year (to Golang [ :| ] )
|
# ? Oct 20, 2019 15:50 |