I have always been impressed by developers who make do without a debugger, and have often wished I could be more like them. I vaguely recall a colleague saying he never used a debugger, favoring
gdb. Also, in my rookie years, I vividly recall chasing a kernel bug with a friend who was using
objdump and the source of a much older kernel:
“Richard, shouldn’t you at least use the correct source?”
“Meh … they’re close enough.”
I’m still impressed.
Now that I have coded for some years, I’ve noticed that I have picked up some bad habits along the way. Over-dependence on the debugger is one of them. I often use it as a high-powered crutch, which frequently leads me waist-deep into stack traces, rarely stopping to think things through. I get lost inside 20 levels of recursion and wonder why an irrelevant variable is being tickled.
Granted, there are many good uses for a debugger, but I’m at 40% on the good use scale. My uses usually start benign but then degrade into cancerous abstractions. So, for my 20th GNU Compiler Collection (GCC) hacking anniversary, I decided to give myself the challenge of one month without a debugger. Here is the tale.
Continue reading “Improve your code: Tales from confinement without a debugger”
OpenJDK is the premier open source Java implementation. The OpenJDK project provides the code used to build Red Hat’s Java releases for Fedora and RHEL and the Java releases used on most other Linux distributions. It also forms the basis of Oracle’s proprietary Java binary releases.
The Red Hat OpenJDK team has been working for some time now, along with organizations like the London Java Community (LJC) and some of our academic partners (e.g. Glasgow & Manchester) to encourage researchers and developers to dive into the innards of OpenJDK’s Java Virtual Machine (JVM) and see how it actually works. One reason is the entirely selfish one that we would like to enlarge the community of potential contributors to the OpenJDK project. Another is that we think it is no bad thing for Java developers, as indeed for any developers, to understand the tools they are using at a deeper level and appreciate how a well designed tool shields them from having to manage some of the more complex aspects of the runtime environment in which their programs execute.
Continue reading “What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK”
This past few weeks I’ve been working on making remote debugging in GDB easier to use. What’s remote debugging? It’s where you run GDB on one machine and the program being debugged on another. To do this you need something to allow GDB to control the program being debugged, and that something is called the remote stub. GDB ships with a remote stub called gdbserver, but other remote stubs exist. You can write them into your own program too, which is handy if you’re using minimal or unusual hardware that cannot run regular applications… cellphone masts, satellites, that kind of thing. I bet you didn’t know GDB could do that!
If you’ve used remote debugging in GDB you’ll know it requires a certain amount of setup. You need to tell GDB how to access to your program’s binaries with a
set sysroot command, you need to obtain a local copy of the main executable and supply that to GDB with a
file command, and you need to tell GDB to commence remote debugging with a
target remote command.
Continue reading “Remote debugging with GDB”
Are you missing out on opportunities to increase your applications’ performance? As an application developer building on Red Hat Enterprise Linux, you invest a lot of time and effort into making your applications compelling and useful for your users. You probably also want to see good performance. But beyond good design, careful algorithm selection and compiler optimizations, what can a developer use to boost their application performance?
1. The latest GCC release and associated tools
The very first thing a Red Hat Enterprise Linux developer should be aware of is the availability of Red Hat Developer Toolset. I described the content and architecture of this new offering from Red Hat in my last blog post. Developer Toolset 1.x gives you the gcc-4.7 toolchain, which, at the time of writing, is the current upstream major release.
Continue reading “7 ways to improve your application’s performance with the new Developer Toolset 1.1 release”
Wouldn’t it be nice if your software development team could use one common set of development tools based on the latest, stable upstream versions for your Red Hat Enterprise Linux development? Think of all the extra years of open source innovation – the features, optimizations and new standards support it would allow your team to build into your products. That would be great, wouldn’t it?
Fortunately, this is already available to you today, and in this blog post I’ll explain how it works and how you can get it. Red Hat Developer Toolset provides a set of additional tools installed in parallel with those delivered as part of Red Hat Enterprise Linux itself. Currently featuring the GCC C/C++ compiler and GDB debugger and backed up by Red Hat’s solid customer support, Red Hat Developer Toolset 1.0 is a great way to unlock performance in your team and your software very easily.
And if you’re already a Red Hat Developer Program subscriber, you can install the tools right now. The Red Hat Developer Toolset version 1.1 Beta, released in October 2012,
showcased a good number of additional performance analysis tools. We’re just getting started with this new offering and have plans to include other tools in the future.
Continue reading “Is your C++ development team missing out? Developer Toolset: newer tools on and for multiple RHEL releases”