Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GDB tricks

blogs.oracle.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: GDB tricks

#21

Post by mwfunk »

zachberger wrote: post #20
lwf wrote: post #9

> By Ksplice Post Importer on Jan 24, 2011 Heh. When interning at Ksplice/Oracle in 2011, I was tasked to import all of the blog posts from the old Ksplice Wordpress blog into Oracle's system. By hand, because they didn't want to turn on the Apache Roller API, or something. I couldn't set a custom author for each post, so instead I changed my name to "Importer, Ksplice Post".

I would have left my internship if I was tasked with that.

Bad engineers are only effective when given tasks that are interesting to them. Good engineers are those who are equally effective when given tasks that aren't so exciting. If you're at the intern level and you're already picking out which tasks are worthy of you and which tasks are beneath you, you may want to think about a different line of work.

Re: GDB tricks

#22

Post by netheril96 »

akshayaurora wrote: post #13

Isn't lldb better option now? Commands are more structured. FWIW, gdb on OSX is a pain to setup, and attaching processes is broken.

I tried LLDB on Ubuntu 12.04, only to find out that it has multiples bugs and no one cares. So no.

My current standing is to use whichever compiler and debugger your platform comes default with: msvc/cdb for Windows, gcc/gdb for Linux and clang/lldb for OS X. Crossing them always reveals tons of bugs, at least for me.

Re: GDB tricks

#23

Post by Everlag »

mwfunk wrote: post #21
zachberger wrote: post #20

Earlier quoted context omitted.

I would have left my internship if I was tasked with that.

Bad engineers are only effective when given tasks that are interesting to them. Good engineers are those who are equally effective when given tasks that aren't so exciting. If you're at the intern level and you're already picking out which tasks are worthy of you and which tasks are beneath you, you may want to think about a different line of work.

While not disagreeing entirely with the core of your argument, an internship should be about learning rather than handing off the work no one else wants to touch. Is is unreasonable to expect, in a position which is reasonably considered a part of your education, that mentorship, controlled exposure to production systems, and legitimate work will be provided?

An internship is not some magical excuse to hire someone likely overqualified to do extremely tangential work for low pay, its a partnership between the intern and the company to perform work that is useful for both the intern and the company.

Its not about being a good or bad engineer, its about the work being relevant. Tasking an apprentice welder to change the oil in the fleet of company cars would be more akin to the scenario described: somewhat related but utterly useless beyond a piece of paper saying they did an internship at X.

Re: GDB tricks

#24

Post by voltagex_ »

sitkack wrote: post #18
cataflam wrote: post #7

These are all useful, and I would even say fundamental, commands. But, as such, these are also very basic commands, not tricks. If you're looking for something more advanced, you'll be disappointed. I strongly suggest to anyone using gdb to just read the manual [0]. Or at least skim it quickly and find a dozen of such useful "tricks" in as many minutes. The time gained in debugging later is well worth knowing and mas…

I found constructing small problems and solving them with GDB when not under pressure greatly expanded my working knowledge. Trying to learn GDB while attempting to solve a time critical production bug is not possible for me.

Have you got any of those problems written down or any pointers for creating them? That sounds like fantastic material for a tutorial.

Re: GDB tricks

#28

Post by cataflam »

sitkack wrote: post #18
cataflam wrote: post #7

These are all useful, and I would even say fundamental, commands. But, as such, these are also very basic commands, not tricks. If you're looking for something more advanced, you'll be disappointed. I strongly suggest to anyone using gdb to just read the manual [0]. Or at least skim it quickly and find a dozen of such useful "tricks" in as many minutes. The time gained in debugging later is well worth knowing and mas…

I found constructing small problems and solving them with GDB when not under pressure greatly expanded my working knowledge. Trying to learn GDB while attempting to solve a time critical production bug is not possible for me.

I can relate to that. When you are not under critical pressure is a great time to print the manual, sit back and try new stuff on some minor bug somewhere.

I actually developed most of my debugging skill when younger, by reverse engineering other programs and games. And after reversing foreign code from the binaries, debugging with the source code seems comfortable. It is also great to get more familiar with the inner working of the processor and to understand what instructions different languages and compilers produce.

It was not with gdb, but debugging is debugging. Switching debugger when you've known a few is like learning a new programming language when you know others, but much easier. You just need to find the new syntax, they're mostly similar.

One thing you learn quickly when REing is also not to jump head first in the debugger. Sometimes your problem can be solved easier using a different route, and that applies to debugging as well. A good read of a promising part of the source code or a well placed debug trace can sometimes be much faster.

For others who want to learn, there are plenty of reverse engineering tutorials you can find with a simple search. I have a particular place in my heart for fravia's (RIP) old website (should still be mirrored by woodmann [0]). It's a bit dated and there may be a better place to start now but it certainly covers some basics.

[0] http://www.woodmann.com/fravia/ You can check out http://www.woodmann.com/forum/content.php for more modern stuff while you're there

Re: GDB tricks

#29

Post by willvarfar »

stormbrew wrote: post #15
akshayaurora wrote: post #13

Isn't lldb better option now? Commands are more structured. FWIW, gdb on OSX is a pain to setup, and attaching processes is broken.

On osx, perhaps. On Linux it's still a little rough. Or was last time I tried to use it. That said, I do look forward to using it more. But most importantly, I look forward to the tooling that can be built around it, since it's much easier to treat it as a library than gdb.

I heard they recently bit the bullet and implemented GDB/MI so lldb can be used by all mainstream IDEs. This doesn't stop lldb-specific targets in IDEs, but it does make them less likely is my guess.

Re: GDB tricks

#30

Post by willvarfar »

lwf wrote: post #9

> By Ksplice Post Importer on Jan 24, 2011 Heh. When interning at Ksplice/Oracle in 2011, I was tasked to import all of the blog posts from the old Ksplice Wordpress blog into Oracle's system. By hand, because they didn't want to turn on the Apache Roller API, or something. I couldn't set a custom author for each post, so instead I changed my name to "Importer, Ksplice Post".

You're famous! Or perhaps infamous, going from a blogging platform with the lackluster codebase to one that doesn't autofit on mobiles and was unreadable on my android chrome as it didn't reflow nor pinch-zoom and was just lots and lots of panning.
Post reply on HN