The State Of GNU's GDB Debugger In 2016

[phoronix]

Phoronix: The State Of GNU's GDB Debugger In 2016

At the GNU Tools Cauldron that took place earlier this month in Hebden Bridge, UK was the annual status update of the GDB debugger...

http://www.phoronix.com/scan.php?page=news_item&px=GNU-GDB-State-2016

[c117152]

How Red Hat took over GCC. A guide:
1. Write all your commits as C++like C and push them upstream over a course of 5-10 years.
2. Wait until all sane maintainers leave (February 2015).
3. Say, "Hey, it's all really bad C looking like C++! Let move to real C++!".
4. Behold: Only your Red Hat devs can maintain GDB\GCC properly.
5. Profit? Nope. People saw C++ coming and figured if they're going to swallow that bitter pill, they might as well do it with CLANG.

Now, moving on to the linux kernel...

[starshipeleven]

How Red Hat took over GCC. A guide:
1. Write all your commits as C++like C and push them upstream over a course of 5-10 years.
2. Wait until all sane maintainers leave (February 2015).
3. Say, "Hey, it's all really bad C looking like C++! Let move to real C++!".
4. Behold: Only your Red Hat devs can maintain GDB\GCC properly.
5. Profit? Nope. People saw C++ coming and figured if they're going to swallow that bitter pill, they might as well do it with CLANG.

Now, moving on to the linux kernel...

[computerquip]

How Red Hat took over GCC. A guide:
1. Write all your commits as C++like C and push them upstream over a course of 5-10 years.
2. Wait until all sane maintainers leave (February 2015).
3. Say, "Hey, it's all really bad C looking like C++! Let move to real C++!".
4. Behold: Only your Red Hat devs can maintain GDB\GCC properly.
5. Profit? Nope. People saw C++ coming and figured if they're going to swallow that bitter pill, they might as well do it with CLANG.

Now, moving on to the linux kernel...

Over Linus' dead body.

[peppercats]

How Red Hat took over GCC. A guide:
1. Write all your commits as C++like C and push them upstream over a course of 5-10 years.
2. Wait until all sane maintainers leave (February 2015).
3. Say, "Hey, it's all really bad C looking like C++! Let move to real C++!".
4. Behold: Only your Red Hat devs can maintain GDB\GCC properly.
5. Profit? Nope. People saw C++ coming and figured if they're going to swallow that bitter pill, they might as well do it with CLANG.

Now, moving on to the linux kernel...

There's no reason to use C in 2016. C-style C++ is vastly superior even if all you use are namespaces.

[notanoob]

Over Linus' dead body.

Well if you have been paying attention there have been some SJW going after Linus as of late(think of the keynote from last year with twitter storm). So over Linus's dead body, maybe. But in these public arenas he is almost surrounded by people so he should be 'safe' no matter how hard they try to defame/murder him.

Another point however is that he has kind of lost some control of kernel development. Most of the developers are from other sources than himself(duh). But a greater majority of commits come from none other than redhat's own kernel dev team.

But on the subject of GDB my mouth waters for some other things in that paper. But the new UI seems kinda overkill, why not just implement a button that switches modes of output/input of terminal commands to gdb commands since they seem to think it is too easy to confuse the two. Two tty's for gdb seems, no IS a huge security risk and just plain silly when they could do it all in the same terminal. It just opens up a giant can of worms if it is used.

I also do not like they are attempting to deprecate C support in gdb? Not sure if I read that correctly towards the end of the slide. It would be fine if they just want a different default interpreter but removing it outright? Surely I read that incorrectly. Although I am certain that they are demodulating GDB so that it has a more client-server relation for how it operates.

[pal666]

How Red Hat took over GCC. A guide:
1. Write all your commits as C++like C and push them upstream over a course of 5-10 years.
2. Wait until all sane maintainers leave (February 2015).

idiot, gcc in c++ push was made by google employee in 2008 http://www.airs.com/blog/archives/187

4. Behold: Only your Red Hat devs can maintain GDB\GCC properly.

lol, it you are idiot, you can' mainain anything anyway. all major compilers are written in c++ and there is a reason for that

5. Profit? Nope. People saw C++ coming and figured if they're going to swallow that bitter pill, they might as well do it with CLANG.

so, idiots magically get ability to maintain properly c++ code but only if it is not in gcc?

[pal666]

Two tty's for gdb seems, no IS a huge security risk and just plain silly when they could do it all in the same terminal.

lol, i see great gdb maintainer is dying in you

[computerquip]

I really don't understand the need for people to change a codebase from C to C++. I get OO-design and abstract types but this doesn't really help in a compiler, not to mention the codebase is probably more data-oriented. If you start a new codebase in C++ or you're overhauling everything because it was bad... fine. That doesn't seem to be what people are doing though. They seem to be taking valid codebases and moving them to C++ for language features they probably shouldn't worry much about in the first place.

[c117152]

idiot, gcc in c++ push was made by google employee in 2008 http://www.airs.com/blog/archives/187
lol, it you are idiot, you can' mainain anything anyway. all major compilers are written in c++ and there is a reason for that
so, idiots magically get ability to maintain properly c++ code but only if it is not in gcc?

The vote was in February 2015. And Ian's work was mainly on Gold and not GDB. Though like most corporate developers, he was pushing for C++ on everything from early on.

And if you're going to quote people asking\suggesting\begging\bribing for more C++ in GCC, you can go as back as the mid-late 80s. And they were always opposed by GNU''s old guard until they all pushed out \ got old by now.

I really don't understand the need for people to change a codebase from C to C++. I get OO-design and abstract types but this doesn't really help in a compiler, not to mention the codebase is probably more data-oriented. If you start a new codebase in C++ or you're overhauling everything because it was bad... fine. That doesn't seem to be what people are doing though. They seem to be taking valid codebases and moving them to C++ for language features they probably shouldn't worry much about in the first place.

Being fair, the problem is the inflexible memory model in C doesn't align too well to how GPUs and DSPs work. It's why C++ is a good choice for games: You need to jump through so many hoops with function pointers aligning buffer in GPUs, that you often just want to wrap that up in a class constructor and be done with it.

So, people who want to debug non-C code with GDB been pushing for C++ additions that will allow GDB to debug everything under the sun.

Of course, a sane person would have made a domain specific language and debugger for those stream operations and niche languages instead of superimposing it on C... But C++ developers are like .Net developers: Hard to read code + needs constant maintenance = job security!

And lets face it, GNU isn't all too unfamiliar with that approach to programming so it really was a marriage made in heaven.