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

The LLDB Debugger

llvm.org

Post reply on HN
Print view View original

11–20 of 36 posts

Re: The LLDB Debugger

#11

Post by alec »

grogers wrote: post #8
pquerna wrote: post #4

Earlier quoted context omitted.

Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python. Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues. Compare t…

Of the tangible features that they list as motivation: - Build libraries for inclusion in IDEs, command line tools, and other analysis tools - gdb seems to have it http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html - High performance and efficient memory use - I cant comment on how much of gdb's sluggishness in running programs is inherent in the problem, and how much is gdb being slow. - Extensible: Python scr…

For "high performance GDB", see tracepoints, which act somewhat like DTrace probes.

Re: The LLDB Debugger

#12

Post by alecco »

lsb wrote: post #5
pquerna wrote: post #4

Earlier quoted context omitted.

Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python. Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues. Compare t…

Yes -- antirez who wrote Redis wrote linenoise, a replacement of the 20k lines of the old GNU readline in about 400 lines of C for only the 99.99% of users who are on VT100 terminals. http://github.com/antirez/linenoise

GNU readline is a bit of a bloated monster but it gives many programs vi-mode. Like gdb.

Re: The LLDB Debugger

#13

Post by pohl »

wazoox wrote: post #10
grogers wrote: post #8

Earlier quoted context omitted.

Of the tangible features that they list as motivation: - Build libraries for inclusion in IDEs, command line tools, and other analysis tools - gdb seems to have it http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html - High performance and efficient memory use - I cant comment on how much of gdb's sluggishness in running programs is inherent in the problem, and how much is gdb being slow. - Extensible: Python scr…

It comes from Apple and is bsd-licensed. In this community, this passes for "enhancements" over gdb. Yes, this is a bitter comment about the HN community state of mind.

Yeah, pesky entrepreneurs and their eye for opportunity.

Re: The LLDB Debugger

#14

Post by wazoox »

pohl wrote: post #13
wazoox wrote: post #10

Earlier quoted context omitted.

It comes from Apple and is bsd-licensed. In this community, this passes for "enhancements" over gdb. Yes, this is a bitter comment about the HN community state of mind.

Yeah, pesky entrepreneurs and their eye for opportunity.

Well, my company only works on gpl stuff and doesn't suffer any inconvenience from that. So I call bluff.

Re: The LLDB Debugger

#15

Post by neilc »

wazoox wrote: post #10
grogers wrote: post #8

Earlier quoted context omitted.

Of the tangible features that they list as motivation: - Build libraries for inclusion in IDEs, command line tools, and other analysis tools - gdb seems to have it http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html - High performance and efficient memory use - I cant comment on how much of gdb's sluggishness in running programs is inherent in the problem, and how much is gdb being slow. - Extensible: Python scr…

It comes from Apple and is bsd-licensed. In this community, this passes for "enhancements" over gdb. Yes, this is a bitter comment about the HN community state of mind.

I think that's far too cynical. gdb is fine, but there is tons of room for improvement, and more competition in this area can only be a good thing. It is early days yet for LLDB, but it is a promising start.

I've yet to see any IDE/debugger setup on a Unixen that comes close to competiting with Visual Studio's debugging interface, as unfortunate as that is.

Re: The LLDB Debugger

#16

Post by wazoox »

neilc wrote: post #15
wazoox wrote: post #10

Earlier quoted context omitted.

It comes from Apple and is bsd-licensed. In this community, this passes for "enhancements" over gdb. Yes, this is a bitter comment about the HN community state of mind.

I think that's far too cynical. gdb is fine, but there is tons of room for improvement, and more competition in this area can only be a good thing. It is early days yet for LLDB, but it is a promising start. I've yet to see any IDE/debugger setup on a Unixen that comes close to competiting with Visual Studio's debugging interface, as unfortunate as that is.

You're absolutely right. However lldb hasn't gone that far so we can't know for sure if it will ever be any better than gdb.

I'll admit easily that gcc messages/gdb debugging actually suck wind :)

Re: The LLDB Debugger

#17

Post by robot »

I hope it replaces the notoriously hard to use gdb. I actually like doing things on the commandline and am used to using minimalistic tools like vim, but gdb's obscure commandline behavior makes it very hard for me to use it for any real project.

Re: The LLDB Debugger

#18

Post by pohl »

wazoox wrote: post #14
pohl wrote: post #13

Earlier quoted context omitted.

Yeah, pesky entrepreneurs and their eye for opportunity.

Well, my company only works on gpl stuff and doesn't suffer any inconvenience from that. So I call bluff.

You're saying that being able to statically link a library into a commercial app has no business value to anybody because you are fortunate enough to have found a niche where you didn't need to. Your personal experience is enviable, but I don't see how it speaks to the general case.

Re: The LLDB Debugger

#19

Post by lallysingh »

wazoox wrote: post #9
yan wrote: post #2

Hopefully this replaces GDB, and good riddance.

Hum, I'd rather wait and see first. What about the truckloads of tools built around gdb (ddd, etc)? And why this should be any better, because it comes from Apple?

Apple employs a few (more than 1?) LLVM people, but it's hardly an Apple project by any means.

LLVM is a substantial and fantastic project. At the basis, it's a compiler backend in-a-box. Additional projects, like clang and this, are providing a modern compiler platform for us, finally. gcc & friends have made great advances, relative to other compilers, but they all do suck.

It's been 12 years and I still can't use C++ in a debugger without jumping through stupidity. It's literally easier to look at a type definition and read the memory out of a hex dump than go through 16 dropdowns of BS subtype definitions.

Re: The LLDB Debugger

#20

Post by yan »

wazoox wrote: post #9
yan wrote: post #2

Hopefully this replaces GDB, and good riddance.

Hum, I'd rather wait and see first. What about the truckloads of tools built around gdb (ddd, etc)? And why this should be any better, because it comes from Apple?

This is my personal opinion, but the tools built around it either use the gdb protocol which I'm sure LLDB will be implemented to speak, or tools that I don't care about (like DDD you mentioned.. it was just a pain to use).

I don't really dislike gdb per se, and it worked well enough for the tasks I used it for, but I just have a personal distaste code conventions of gdb, gcc and other huge GNU projects. I tried spelunking around gdb source to get at some OS X-specific features and tried adding simple instrumentation to GIMPLE trees in gcc's implementation, and both experiences left me with a negative opinion of GNU coding conventions and showed both projects' age. Looking at LLVM source and following their mailing lists is anything but, showing clear direction and clean implementation. I'm not a compiler guy by any stretch of the imagination, but LLVM felt very well-architected and modern.

Apple sponsored LLVM after I started following it, so while it's true that they are behind it, it has very little to do with my respect for it.

Post reply on HN