Live data from Hacker News

GDB 8.1 Released

sourceware.org

51–60 of 62 posts

Re: GDB 8.1 Released

#51
post #47
post #44

Earlier quoted context omitted.

Why not use a real GUI frontend like Visual Studio Code instead?

Can you use VSCode as just a debugger? IDE's typically require sacrifices like letting the IDE take over your build process.

Yes :) Install the Native Debug extension and then configure the debugger in the launch.json file.

Re: GDB 8.1 Released

#52
post #40
post #15

starti, rbreak and ptype sound good even if they've been available as idioms before.

starti did not exist before, and specifically addresses a StackOverflow question of mine from ~3 years ago: https://reverseengineering.stackexchange.com/questions/8724 ptype already existed, but did not print out offsets. This is incredibly useful, and something Windbg does with dt . Pwndbg does this in GDB by adding new commands.

Presumably the stackexchange answer is what OP meant by it being an idiom.

Re: GDB 8.1 Released

#53
post #22
post #2

Cool, but why are the release checksums in MD5?

Ah yes, the standard nitpicky dismissive HN comment makes its appearance.

I see just a question, nothing "nitpicky dismissive" ? Has the comment been edited into a more neutral tone ?

Re: GDB 8.1 Released

#54

Earlier quoted context omitted.

One use case would be to have some debug_printf() in the program that shows up in the debugger, no matter whether the debugger is remote or local. It doesn't go to some console, or file, but always to the debugger. The Microsoft environment has something like this: OutputDebugString. Very useful. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... Also IsDebuggerPresent: https://msdn.microsoft.com/en-us/l…

You don't need OutputDebugString on because you can always tap the write syscall on stdout from gdb. And I don't really know what IsDebuggerPresent gets you. You're really focusing on features, rather than use cases.

Well, stdout isn't a debug channel; you might want to debug a program that actually uses stdout for its output, not for debug chatter.

Never mind that though, we can take some other descriptor, like 3, and bind it to, say /dev/null.

What are the gdb commands to have whatever is going to file descriptor 3 be shown inside gdb?

I really do not care how it's implemented. However, "tightly integrated" is better than "flimsy hack"; "consumes breakpoints" is better than "doesn't consume breakpoints".

Re: GDB 8.1 Released

#55

Earlier quoted context omitted.

If those non-malware programs are fixed to use a proper API instead of side channel hacks, then it simplifies analysis.

> If those non-malware programs are fixed to use a proper API instead of side channel hacks, then it simplifies analysis. I think you’re missing the point as to why programs would do this. Usually it’s to protect some sort of DRM scheme through obscurity.

[deleted]

Re: GDB 8.1 Released

#56

Earlier quoted context omitted.

You don't need OutputDebugString on because you can always tap the write syscall on stdout from gdb. And I don't really know what IsDebuggerPresent gets you. You're really focusing on features, rather than use cases.

Well, stdout isn't a debug channel; you might want to debug a program that actually uses stdout for its output, not for debug chatter. Never mind that though, we can take some other descriptor, like 3, and bind it to, say /dev/null. What are the gdb commands to have whatever is going to file descriptor 3 be shown inside gdb? I really do not care how it's implemented. However, "tightly integrated" is better than "flim…

> Well, stdout isn't a debug channel; you might want to debug a program that actually uses stdout for its output, not for debug chatter.

What's your use case for this that makes stderr unsuitable?

Re: GDB 8.1 Released

#57
post #50
post #40

Earlier quoted context omitted.

starti did not exist before, and specifically addresses a StackOverflow question of mine from ~3 years ago: https://reverseengineering.stackexchange.com/questions/8724 ptype already existed, but did not print out offsets. This is incredibly useful, and something Windbg does with dt . Pwndbg does this in GDB by adding new commands.

Does this mean p does not work anymore, because there are now 2 commands starting with p? This would be a shame.

I checked it out. p still works as before.

But I needed a C++ patch on osx with cc/clang. Apparently they added cxx files with the .c extension: gdb/probe.c:63

    - const any_static_probe_ops any_static_probe_ops;
    + any_static_probe_ops any_static_probe_ops;

Re: GDB 8.1 Released

#58
post #35
post #22

Earlier quoted context omitted.

Ah yes, the standard nitpicky dismissive HN comment makes its appearance.

I’m quite amazed we’ve made it to 33 comments without somebody complaining it the project hasn’t been retooled with Rust/Clojure/Node.js yet.

There is no point on reimplementing GDB yet, you need first a legacy debugger with proper Rust support until the new one can debug itself.

Re: GDB 8.1 Released

#59
post #47
post #44

Earlier quoted context omitted.

Why not use a real GUI frontend like Visual Studio Code instead?

Can you use VSCode as just a debugger? IDE's typically require sacrifices like letting the IDE take over your build process.

Yep! This is all of the configuration needed to use VSCode as a debugger for Ocaml:

https://i.imgur.com/kY6NuXC.jpg

Re: GDB 8.1 Released

#60
post #56

Earlier quoted context omitted.

Well, stdout isn't a debug channel; you might want to debug a program that actually uses stdout for its output, not for debug chatter. Never mind that though, we can take some other descriptor, like 3, and bind it to, say /dev/null. What are the gdb commands to have whatever is going to file descriptor 3 be shown inside gdb? I really do not care how it's implemented. However, "tightly integrated" is better than "flim…

> Well, stdout isn't a debug channel; you might want to debug a program that actually uses stdout for its output, not for debug chatter. What's your use case for this that makes stderr unsuitable?

stderr also isn't for debug output.

If, say, a compiler puts out "hello.c: syntax error" on its standard error stream, that is not a debugging diagnostic regarding that compiler's internals; it's about "hello.c".

stderr is not an instrumentation tool which goes away when we're not debugging the program.

Post reply on HN