• 2010_GCC_Summit_BoF

GDB BoF at the 2010 GCC Summit.

Minutes of the GDB BoF - Tuesday October 26th, 2010

Tom Tromey hosted a BoF on GDB. To be added later are Tom's note taken during that session.

GDB Meeting - Wednesday October 27th, 2010

We tried to gather most of the GDB contributors present at the Summit in order to have an informal technical discussion on various topics related to GDB.

Present at the meeting (from memory):

• Eric Bachalo
• Joel Brobecker
• Sergio Durigan Jr.
• Doug Evans
• Jan Kratochvil
• Phil Muldoon
• Keith Seitz
• Tom Tromey
• Ulrich Weigand

• let's load all by default, and worry about performance issues if/when they happen
• Testscase that test command completion, might be affected.
  • Do we want a new command-line option -np to deactivate this auto-loading?
  • Or should -nx turn off Python?

Decision: Load all commands by default, give option to turn them off

It would probably be convenient to design a user-writable area where the user could put his own scripts and have GDB automatically load them. But it's just as easy for people to auto-load their scripts via the .gdbinit file.

To be discussed on the development mailing list whether it's desirable, and if yes, then how.

The question comes from the fact that we are about to start developing more and more features in Python. Is a GDB without Python going to make sense in the long run?

Most of us don't want to force Python as a mandatory dependency.

Some features are going only ever going to be done in Python, but most of the time, the feature is not going to be essential enough that people will want to rewrite them directly in C.

Problem: Testing when built without Python. Perhaps have a build bot do the testing regularly.

Target code duplicated. Often actually quite complicated, so it's bad to have two copies. We should make the code common, it's just a matter of doing the job (which is likely to be quite complex...)

Moving to any versioning system, whether it is SVN or git, is so much harder because of the fact that we are dependent on other projects, and on the partial-checkout feature in CVS.

We have a git mirror that is currently read-only. Perhaps we should allow development branches on it (to help people share some changes through feature branches, for instance).

• Poll the maintainers of the other projects sharing `src' to see what they think (who cares, who doesn't, etc).
• Figure out a plan for the transition to propose and discuss. Refer to email from Joseph Meyer about criteria for this transition to be possible (would be a good place to start).
• Move htdocs to git?

Currently, we have two copies of the GDB Web pages: One under htdocs for sourceware.org, and another on Savannah for gnu.org. This is highly inconvenient, because changes to one side (typically htdocs) need to be duplicated on the gnu.org side. This is even more difficult as write access priviledges require a savannah account and then sending a request to someone who is no longer actively maintaining GDB. The bottom line is that most of the changes are made by Joel.

• We need to find a way to improve the situation.

Can we re-use the C++ frontend in GCC? The C++ parser in GDB is not complete and working on completing it might be more work than re-using another parser. RH has started a research project on that.

Architectures with large number of CPUs/cores are becoming more and more predominant. Are there ways we can improve GDB to help the developers debug more effectively on these architectures? For instance, in the slightly longer range, we want to be able to do cluster debugging

[Note from the minutes taker: I don't remember if some other ideas came up]

At the internals level, are there areas where areas in the GDB code (besides debug-info reading) where threads would be useful to improve performance?

When working on a change that becomes larger than usual, a developer can become nervous about it not being well received. The worry is that the change itself being either rejected, or having to be heavily reworked.

The best way to avoid this from happening is to start an early discussion in orderto make sure that we agree on the idea before going through the process of making the changes. But sometimes, little or no feedback is received. More involvement in the discussion would be nice.

One idea that came up in the past was to write a tool that would allow a user to control several GDB instances at the same time, instead of having GDB handle multiple targets/inferiors. But experiments suggest that this is not the best approach, and having one single GDB process makes more sense.

This confirms the direction that has been taken in GDB, where the goal is to be multi-target/multi-inferior.