techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

4.6K
active users

#debug

3 posts3 participants0 posts today
Replied in thread

@stefano

Your example of the win_modems is a perfect one. Those monstrosities were just generic cards without the 16550 AF UART on them.

That means they were not modems at all.

It also means that people who told you just install windows and it's good, didn't know anything about how the mechanics and the hardware works...

It's exactly the same with software that has been written with cross-compatibility in mind. Either the programmer should test it and compile it in different other operating systems or she/he should ask someone else to take the task upon him, to at least do a test compilation otherwise dependencies upon dependencies, nested, will never be found

A good programmer at least puts into readme file, in which Operating Systems he test compiled his program

Oh joy, another thrilling exposé on the *"mysterious"* #JTAG lurking in your Snapdragon's #USB port — because who wouldn't want to tinker with #hidden #debug interfaces on their phone? 🤔🙄 Clearly, nothing screams "party" like rummaging through the "exhilarating" depths of a #Linaro #blog. 🎉🔧
linaro.org/blog/hidden-jtag-qu #mysterious #Snapdragon #tinkering #HackerNews #ngated

www.linaro.orgThe hidden JTAG in your Qualcomm/Snapdragon device’s USB port | Blog | LinaroLearn about JTAG and EUD

Let's Build a Golang Debugger From Scratch!

Hey everyone! I'm excited to share my new eBook, "Debugger101: The Art of Debugging in Go", where we’ll build a debugger from the ground up.

🔍 ​What’s inside?​​

A deep dive into debugging concepts
Step-by-step guidance on crafting your own Go debugger
Practical insights to level up your debugging skills
📖 ​Read it here:​​ hitzhangjie.github.io/debugger

hitzhangjie.github.io1 Introduction · GitBook

Wrote a blog post on how to use strace to better debug programs:
rrampage.github.io/2025/06/13/

A Random Walk · strace tips for better debuggingRecently, I have been building software without libc to better understand Linux syscalls and internals better. So far, I have built a minimal shell, terminal Snake game, pure ARM64 assembly HTTP server and threads implementation. I have been using strace extensively while debugging. Useful options and flags I use a version of the following command: strace -fintrCDTYyy -o strace.log -v -s128 ./binary This looks like an alphabet soup of options! Here’s what they do and how they are useful: -f: Follow child processes/threads. This is especially useful when dealing with spawning processes or threads as otherwise, strace will only trace the parent process. -v: Print unabbreviated versions of environment, stat, termios and other structs in syscalls. I found this invaluable in conjunction with -s when doing assembly programming to check if the structs were being initialized correctly and if certain arguments were being sent in little/big endian format -s NUM: Specify the maximum string size to print. Useful for large structs -o: Save strace output to a log file. It is always better to do this to investigate the output of the original process and strace separately without each cluttering the other -yy: Print all available information associated with file descriptors. This is great for expanding the file descriptor to either its full path in case of a file or TCP address in case of sockets -Y: Print command names for PIDs. I found this useful when building the shell to check if the correct program is being executed -t: Print current timestamp in log -T: Show time spent in syscalls. Useful for some basic profiling although strace heavily slows down the process. -r: Print a relative timestamp upon entry to each system call -n: Print syscall number. Great to quickly find out syscall numbers on new architectures. -i: Print instruction pointer at the time of syscall. Found this useful when debugging assembly code to check rough location of errors. -C: Print summary of syscall count, time, errors at the end of regular output Print stack traces The -k or --stack-trace prints the stacktrace along with the syscall. This is useful if your program is compiled with with -g. This post is a good read on using strace to show backtraces for a Golang program compiled with GODEBUG.