* Will therefore GDB utilize C++ or not? @ 2012-03-30 16:14 Jan Kratochvil 2012-04-04 20:48 ` Tom Tromey 0 siblings, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-03-30 16:14 UTC (permalink / raw) To: gdb Hi, there is now new patch: Re: [PATCH] Allow 64-bit enum values http://sourceware.org/ml/gdb-patches/2012-03/msg00932.html which is a pre-requisite for GDB inferior type fields safety similar to what I already checked in as: [commit] [patch 2/2] typedef-checking for CU relative vs. absolute offsets http://sourceware.org/ml/gdb-patches/2012-03/msg00721.html But compared to the [commit] patch of only 282 '+' lines limited to dwarf* files only above the type fields safety patch will be huge and thorough the whole GDB codebase (TYPE_LENGTH: 1103 lines, FIELD_BITPOS: 22 lines, sure the patch will be larger).. -> This whole effort is wrong if GDB was in C++ which allows to use: http://en.wikipedia.org/wiki/Object_type_%28object-oriented_programming%29#Boxing so that one can directly use type->length as long as it is safe, an example of C++ solution is given below. It no longer needs to patch every use of TYPE_LENGTH into some TYPE_LENGTH_VAL or to append '.cu_off' to every use of the "integer" like I did in the [commit] patch above. There are sure many other cases I still wait to solve using C++. There was some plan to have GDB exceptions and cleanups converted to C++ exceptions and RAII http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization automatic allocation/deallocation which would automatically solve many other bugs being fixed by hand here and there. I have filed also crashes from stale frame_info * http://sourceware.org/bugzilla/show_bug.cgi?id=13866 which would be easily sanity-protected by mandatory referencing frame_info * by C++ smart-pointer and during reinit_frame_cache just assert there are no live instances of frame_info references out there etc. etc. For switching GDB compilation to C++ there is needed to resolve some name clashes first http://sourceware.org/gdb/wiki/ArcherBranchManagement Enabling gdb to compile with the -Wc++-compat flag to gcc. archer-ratmice-compile-Wc++-compat but there is enough workforce to do this mechanical type of work as long as there is an agreement to switch to C++. To C++ or not to C++? Unfortunately the discussion was here already before and I am aware several contributors are not welcome with it, I think it does not need to affect readability of C code much, there is not enough workforce to rewrite all the GDB code into C++ style anyway. Still C++ would help a lot, some kinds of bugs are not solvable without it. I am open to suggestions of static analysis tools to use instead but at least according to the experience of Tom Tromey it is not so easy / safe / foolproof to use, IIUC his words. Thanks, Jan #include <stdint.h> class Length { int64_t _x; public: Length(int64_t x) { _x = x; } operator int64_t() { return _x; } private: operator int() { return _x; } }; void ok (int64_t l) {} void bad (int l) {} void bad2 (long long l) {} int main() { Length l(10); // great, no errors ok (l); // error: ‘Length::operator int()’ is private // error: within this context // note: candidates are: // note: Length::operator int() // note: Length::operator int64_t() // error: initializing argument 1 of ‘void bad2(long long int)’ bad (l); // error: conversion from ‘Length’ to ‘long long int’ is ambiguous bad2 (l); } ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-03-30 16:14 Will therefore GDB utilize C++ or not? Jan Kratochvil @ 2012-04-04 20:48 ` Tom Tromey 2012-04-04 21:55 ` Mark Kettenis ` (4 more replies) 0 siblings, 5 replies; 116+ messages in thread From: Tom Tromey @ 2012-04-04 20:48 UTC (permalink / raw) To: Jan Kratochvil; +Cc: gdb >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: Jan> To C++ or not to C++? Unfortunately the discussion was here Jan> already before and I am aware several contributors are not welcome Jan> with it, I think it does not need to affect readability of C code Jan> much, there is not enough workforce to rewrite all the GDB code Jan> into C++ style anyway. Still C++ would help a lot, some kinds of Jan> bugs are not solvable without it. I'm strongly in favor of C++ for reasons I'll lay out below. I agree with all your points. But first: Jan> I am open to suggestions of static analysis tools to use instead Jan> but at least according to the experience of Tom Tromey it is not so Jan> easy / safe / foolproof to use, IIUC his words. Yes, when David Malcolm wrote his Python plugin for GCC, I decided to see whether we could get the equivalent maintainability benefits of C++ by writing in C and then using static analysis to fill the gaps. To this end I wrote a few small plugins to do analysis on gdb. My conclusion is that it is just too much work to iron out all the false reports from the plugins. Partly this is due to gdb's unusual structure, in particular the use of cleanups, which mean that any analysis requires a lot of hair to ensure its correctness. Last June (so long ago already?) I sent a draft of a proposal to migrate gdb to C++ to the Archer list (the thread is http://sourceware.org/ml/archer/2011-q2/threads.html#00028; the followups are worth reading, but I've incorporated most of it into the below). After some discussion and edits, I chickened out of sending it. Here it is now: At the GCC Summit, I once again brought up the perennial idea of moving GDB to be implemented in C++. There, we agreed that as a follow-on to that discussion that I would raise the topic among the GDB maintainers, and in particular present my migration plan. My goal for moving to C++ is to make GDB more robust. My view is that GDB is already written in a poor cousin of C++. Nearly every feature that people hate about C++ is already in use in GDB. This list is not exhaustive, just informational: * Subclasses. See general_symbol_info. struct value and struct type would be improved by them. * Virtual functions. gdbarch, languages, and values all use these. * Overloaded functions. Anywhere you see a _1 suffix. * Templates. Both observers and VEC are templates. * Exceptions. Used ubiquitously. * RAII. Cleanups, but they are dynamic and more error-prone. * Even global constructors -- init.c. In most cases, GDB's implementation of these features is inferior to that of the C++ compiler. Its exceptions are slower. Its data structures have less type-safety. Both cleanups and TRY_CATCH are error-prone in practice. GDB is needlessly verbose due to using callback-based container iteration and callback-based exception handling. We have run into various situations where errors could have been prevented through the use of better type-safety -- e.g., wrapper classes for the CU- versus section-offset case. I think a gradual move to C++ would enable us to fix these problems. I believe it would also provide us a way to fix the ongoing reference counting bugs in the Python layer. I don't believe we should convert all of GDB to C++. In particular I think gdbserver should remain as pure C, and likewise any code shared between gdbserver and gdb should be kept as such. I also think we should be reasonably conservative in our choices of C++ constructs to use. I think this should be a separate thread; I will be happy to write a draft proposal for this as well. We can also see what the GCC community comes up with here -- our needs are a little different, but probably not drastically so. My concrete transition proposal is: 1. Modify GDB so it can be compiled with -Wc++-compat. This would be the first patch series. There is already an archer branch for this. 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is not complete). This would be the second patch series. 3. Require C++. 4. Change selected modules to use C++ rather than C. I don't think a wholesale change makes sense, but some areas would benefit. My first target would be to change the exception handling system to use C++ exceptions. This would enable us to begin using RAII in some areas, which would help robustness. My concrete plan here is: * Use the GCC cleanup-checking plugin I already wrote to detect cleanup-aware functions. * Modify these functions, using a script, to add an RAII-using object to manage the local cleanups. This is important so that we run cleanups at the correct time during stack unwinding. * Change throw_exception to use 'throw' and all TRY_EXCEPT instances to try...catch. * Finally, convert functions to static RAII usage when appropriate; this will be an ongoing transition. I think our second target will be sorting out Python reference counting, so we can avoid the many problems we have had there. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-04 20:48 ` Tom Tromey @ 2012-04-04 21:55 ` Mark Kettenis 2012-04-05 3:31 ` Sergio Durigan Junior 2012-04-05 11:46 ` Phil Muldoon 2012-04-05 0:22 ` Will therefore GDB utilize C++ or not? asmwarrior ` (3 subsequent siblings) 4 siblings, 2 replies; 116+ messages in thread From: Mark Kettenis @ 2012-04-04 21:55 UTC (permalink / raw) To: tromey; +Cc: jan.kratochvil, gdb > From: Tom Tromey <tromey@redhat.com> > Date: Wed, 04 Apr 2012 14:47:39 -0600 > > >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: > > Jan> To C++ or not to C++? Unfortunately the discussion was here > Jan> already before and I am aware several contributors are not welcome > Jan> with it, I think it does not need to affect readability of C code > Jan> much, there is not enough workforce to rewrite all the GDB code > Jan> into C++ style anyway. Still C++ would help a lot, some kinds of > Jan> bugs are not solvable without it. > > I'm strongly in favor of C++ for reasons I'll lay out below. And my position on this has not changed: I'm strongly against. C++ is horrible language that should never have been invented. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-04 21:55 ` Mark Kettenis @ 2012-04-05 3:31 ` Sergio Durigan Junior 2012-04-05 11:46 ` Phil Muldoon 1 sibling, 0 replies; 116+ messages in thread From: Sergio Durigan Junior @ 2012-04-05 3:31 UTC (permalink / raw) To: Mark Kettenis; +Cc: tromey, jan.kratochvil, gdb On Wednesday, April 04 2012, Mark Kettenis wrote: >> From: Tom Tromey <tromey@redhat.com> >> Date: Wed, 04 Apr 2012 14:47:39 -0600 >> >> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: >> >> Jan> To C++ or not to C++? Unfortunately the discussion was here >> Jan> already before and I am aware several contributors are not welcome >> Jan> with it, I think it does not need to affect readability of C code >> Jan> much, there is not enough workforce to rewrite all the GDB code >> Jan> into C++ style anyway. Still C++ would help a lot, some kinds of >> Jan> bugs are not solvable without it. >> >> I'm strongly in favor of C++ for reasons I'll lay out below. > > And my position on this has not changed: I'm strongly against. C++ is > horrible language that should never have been invented. I believe I understand your "rationale", but I would like to know if the approval (by the majority) and eventual use of C++ in GDB (mentioning, again, that GDB will not be rewritten in C++) would make you stop contributing to the project. I am not a maintainer, and I understand that C++ is not the best language out there, but I've seen (more than once) other people saying that "if the project ABC adopts XYZ, then I'm out". I don't think this is the most reasonable thing to do, and I'm pretty sure this kind of behaviour slows down some kinds of progresses (such as this C++ thing), mostly because nobody wants to miss talented (and needed!) people contributing to the project, I think. That's why I'm asking you this question (but really, I would be asking to anyone objecting with arguments like "the language is horrible"). Thanks, -- Sergio ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-04 21:55 ` Mark Kettenis 2012-04-05 3:31 ` Sergio Durigan Junior @ 2012-04-05 11:46 ` Phil Muldoon 2012-04-06 0:35 ` Will therefore GDB utilize C++? Not John Gilmore 1 sibling, 1 reply; 116+ messages in thread From: Phil Muldoon @ 2012-04-05 11:46 UTC (permalink / raw) To: mark.kettenis; +Cc: gdb On 04/04/2012 10:55 PM, Mark Kettenis wrote: >> From: Tom Tromey <tromey@redhat.com> >> Date: Wed, 04 Apr 2012 14:47:39 -0600 >> >>>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: >> >> Jan> To C++ or not to C++? Unfortunately the discussion was here >> Jan> already before and I am aware several contributors are not welcome >> Jan> with it, I think it does not need to affect readability of C code >> Jan> much, there is not enough workforce to rewrite all the GDB code >> Jan> into C++ style anyway. Still C++ would help a lot, some kinds of >> Jan> bugs are not solvable without it. >> >> I'm strongly in favor of C++ for reasons I'll lay out below. > > And my position on this has not changed: I'm strongly against. C++ is > horrible language that should never have been invented. Beyond the obvious question of "why is it a horrible language", I'd like to ask you to consider another approach. Is it because of some horribly obfuscated C++ code out there you may have witnessed? You know the type, takes take the OOP concept and batters it to atoms? Useless implementation of esoteric template designs, not because it is needed, but because it was cool? There is a lot of C++ code that I do not like, but there is also a lot of C code that sucks too. I've written some. We all have, at some point. There is some in GDB. My belief is that you can write clear, concise, efficient code in any language; similarly, you can write complete rubbish in any language too. C++ debates seem to be a fertile garden for this kind of discussion, but, eventually, I recognized I was criticizing the implementer/implementation of the project, not the language itself. So focusing on the language, and not any previous implementations one might have witnessed, what is acceptable? My approach to the discussion is C++ is OK, as in a "C with objects" approach. That may be too far for you, and not far enough for others. But it is a point to defend and/or compromise on. Personally, I don't think GDB is going to go crazy with variadic templates, or other concepts I am not totally keen on. And, I think, maintainers need a balance of skeptics and champions, to balance this out. Every line of code that goes into GDB is subject to review -- even by global maintainers themselves. That's why this discussion is not opening the flood-gates, but creaking them open a little. Say this discussion results in C++ being acceptable. Every patch still has to be posted, reviewed and (if not a maintainer) approved. There are safeties at every turn. So, please, if you can write a concise argument, I for one would like to read it. Balance is good, but arguments that we cannot challenge, or defend just lead us to a dead-end. Cheers, Phil ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-05 11:46 ` Phil Muldoon @ 2012-04-06 0:35 ` John Gilmore 2012-04-06 1:35 ` Russell Shaw 0 siblings, 1 reply; 116+ messages in thread From: John Gilmore @ 2012-04-06 0:35 UTC (permalink / raw) To: Phil Muldoon; +Cc: mark.kettenis, gdb I introduced many of the "tables of C pointers" into GDB. I could've opted to switch to C++ at that point. I did not and am happy that I did not. The paradigms we introduced were simple, maintainable, useful, and documented. I see nothing wrong with writing in C and occassionally using a table of pointers (like the dispatch tables in BFD, or the target selectors) where appropriate. Just because you sometimes call through a pointer, or arrange values in data structures, doesn't mean you need to "move to an object oriented language". People who can't do object-oriented programming in a procedural language perhaps don't understand object-oriented programming, which is not about syntax, nor about enforcement, but about deliberately choosing a narrower subset of mechanisms to produce programs that are easier to maintain. One of our original reasons for sticking with C is less relevant today. GDB is one of the first programs you want to bring up on a new system, since it can help you debug itself and every other program. To be useful for that, it needed to be compilable with a very broad spectrum of relatively simple compilers. Being written in C++ would have foiled that. Nowadays we merely cross-compile and cross-debug, or emulate the target system from some well-supported host system. Avoiding the need for a tricky, complicated, and working compiler to compile GDB is less of a constraint. I have not yet found an easy-to-maintain large production C++ program; not in 1991 and not in the intervening 20 years. I've written a medium sized C++ program (smqueue). Based on that experience, I was never tempted to write a large program in C++. I have found many C++ programs that are hard to maintain. Hard to understand, hard to compile, hard to debug. As an example, I am currently wrestling with a commercial success, a production program running at thousands of sites, that took 12 years of a team of half a dozen programmers to write and maintain in C++. It now no longer even compiles, because the recently graduated programmers who wrote it embedded questionable C++ constructs deep into its infrastructure, and failed to document the structures they were building. I could and will rewrite the broken parts, but it's very painful to even understand what they were TRYING to do, because it's undocumented and wrapped up in layer after layer after layer of templates and inclusion and C++ junk. They aren't making objects that have accessors and such; they're using a "pattern language" that abuses C++ objects to do cheap runtime type-checking -- or something! It took hours to just narrow the program down to a one-page program that would reproduce the compiler error while being something a human could grasp. Of course every C++ programmer denies that they are designing or writing a monster like that. However, a surprising number end up that way. It is much harder to screw up a C program beyond human recognition. There's not even a contest for Obfuscated C++, since it's trivial to do without even intending to! C++ fails at simplicity and predictability. The 1990's idea that C++ was the obvious successor to C has clearly been proven false over the last 25 years. C is still here and going strongly. C++ was an experiment that disproved its thesis -- a valuable contribution, certainly, but not an example to follow. Even the thesis that objected oriented programming is superior to traditional procedural programming has been disproved (in my mind), or is at least unresolved at this date. I would say that over the last 20-40 years the key new insights in programming have been in portability, simplicity, and pan-global collaboration of focused teams (version control, automating distributed discussions and bug reports, distribution, packaging, etc). The mainstream of system and application development continues in directions other than C++, such as C, Java, and Python, not to mention big corners like PHP, C# and Objective-C. If you ended up writing parts of GDB in C++ and other parts in C, anyone who did maintenance on it would have to understand both. But C++ is full of ugly traps for the unwary, and things seldom mean what they appear to a C programmer to mean. You'd narrow your potential pool of talented contributors. And you'd be basing your core debugger on one of the least well supported parts of C++ -- its interoperability with traditional C code. I do not recommend that GDB use C++. John ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 0:35 ` Will therefore GDB utilize C++? Not John Gilmore @ 2012-04-06 1:35 ` Russell Shaw 2012-04-06 13:16 ` Joel Brobecker 0 siblings, 1 reply; 116+ messages in thread From: Russell Shaw @ 2012-04-06 1:35 UTC (permalink / raw) Cc: gdb On 06/04/12 10:34, John Gilmore wrote: ... > I do not recommend that GDB use C++. I agree 100% on all points. I came to the same conclusions 10 years ago. Everything i do now is C, and i only poke with C++ to grab something out of it or to reverse engineer. Most C++ programmers i've seen have this mentality that they don't need to know what's "under the hood" such as what some library is doing or how inefficient it is. As a result, you get layers upon layers upon layers of absolute crud piled sky high. OTOH, i don't recommend trying to emulate C++ in plain C, or you end up with a maintenance disaster like GTK. All it requires is a few more short lines of explanatory design notes scattered through the code and clarity of thought. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 1:35 ` Russell Shaw @ 2012-04-06 13:16 ` Joel Brobecker 2012-04-06 14:43 ` Russell Shaw ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: Joel Brobecker @ 2012-04-06 13:16 UTC (permalink / raw) To: gdb > >I do not recommend that GDB use C++. > > I agree 100% on all points. I came to the same conclusions 10 years > ago. Everything i do now is C, and i only poke with C++ to grab > something out of it or to reverse engineer. I wish we would stop discussing about the language itself, and argue the technical points that the pro-C++ camp were bringing up. There are a number of issues with GDB's design there were raised, and solutions involving the use of C++ were proposed. As far as I know, the anti-C++ camp has rejected C++ in general based on general and vague arguments, rather than argue the specific points that have been brought up. We are NOT talking about using ALL of C++, we are talking about using a reasonable subset that would allow us to expand a bit what the language can do for us. If the non-discussion continues, we're going to have to make a decision on how to decide on this issue, and I am afraid that the only fair way would be for the Global Maintainers to vote. To my knowledge, we have never resorted to such an extreme approach, but I don't see a real discussion happening here. > Most C++ programmers i've seen have this mentality that they don't > need to know what's "under the hood" such as what some library is > doing or how inefficient it is. Please, we're talking about the GDB Maintainers and the few contributors who actually participate in GDB's development. This argument means nothing because the only side-effect is that such programers would be limited in how much they can contribute. But on the other hand, if we follow your reasoning, they would not be able to contribute anyway, since using C makes the language too low-level for them. I will just go out and say it, but I think about half of the active maintainer, if not more, are in favor of using some features of C++. And I can tell you right here and now that they are no dummies. > OTOH, i don't recommend trying to emulate C++ in plain C, or you end > up with a maintenance disaster like GTK. And yet, that's exactly what we are doing: - unit elaboration; - gdbarch/language dispatching - exception handling - use of unions to emulate polymorphism; - etc, etc, etc. And frankly, you criticize GTK's design, but it was exactly the design I was thinking about of emulating if we wanted a more OO approach without using C++. To my knowledge, KDE is doing very well, and is written in C++. So again, the proposal that was put on the table a long time ago was that some specific features of C++ be used in order to simplify certain areas of GDB's code. The pro-C++ camps has, in my opinion, successfully shown how C++ was going to help. The specific arguments, in my opinion, should be brought up again, and those specific arguments should be discussed, rather than just discussing generalities about how horrible C++ is. > All it requires is a few more short lines of explanatory design > notes scattered through the code and clarity of thought. This is almost offensive. If it was that easy, how about you start sending some patches? -- Joel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 13:16 ` Joel Brobecker @ 2012-04-06 14:43 ` Russell Shaw 2012-04-06 15:34 ` Michael Eager 2012-04-06 23:32 ` John Gilmore 2 siblings, 0 replies; 116+ messages in thread From: Russell Shaw @ 2012-04-06 14:43 UTC (permalink / raw) Cc: gdb On 06/04/12 23:16, Joel Brobecker wrote: >>> I do not recommend that GDB use C++. >> ... >> All it requires is a few more short lines of explanatory design >> notes scattered through the code and clarity of thought. > > This is almost offensive. If it was that easy, how about you start > sending some patches? I made up a heap of gdb patches over several months for a microcontroller a few years ago, and used those patches for real work. There was still a bit of buggyness i couldn't fix. I did not submit them because i could not verify them in a robust way due to the gdb internals documentation i found very lacking, but my (lack of) knowledge of unix process handling was a contributor too. I definitely would not have put in the effort if it meant dealing with C++. I'm not doing any gdb work until i understand how the debugging format works. There is not much documentation on that. The coding is easy. Lack of documentation is the hard part. Using C++ isn't magically going to make the internals of gdb easier to maintain. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 13:16 ` Joel Brobecker 2012-04-06 14:43 ` Russell Shaw @ 2012-04-06 15:34 ` Michael Eager 2012-04-06 23:32 ` John Gilmore 2 siblings, 0 replies; 116+ messages in thread From: Michael Eager @ 2012-04-06 15:34 UTC (permalink / raw) To: gdb On 04/06/2012 06:16 AM, Joel Brobecker wrote: >>> I do not recommend that GDB use C++. >> >> I agree 100% on all points. I came to the same conclusions 10 years >> ago. Everything i do now is C, and i only poke with C++ to grab >> something out of it or to reverse engineer. > > I wish we would stop discussing about the language itself, and argue > the technical points that the pro-C++ camp were bringing up. There are > a number of issues with GDB's design there were raised, and solutions > involving the use of C++ were proposed. As far as I know, the anti-C++ > camp has rejected C++ in general based on general and vague arguments, > rather than argue the specific points that have been brought up. We are > NOT talking about using ALL of C++, we are talking about using > a reasonable subset that would allow us to expand a bit what the language > can do for us. I'll echo Joel -- complaints about C++ language design don't add much to the discussion. I've long been an advocate of C With Classes. I'm less in favor of using other features in C++, perhaps not so much from the technical concerns, which I do have, but because gcc provides horrible C++ error messages and gdb provides horrible C++ debugging. It's been suggested that if gcc/gdb converted to C++ that both would improve as the developers ate their own dog food. > And yet, that's exactly what we are doing: > - unit elaboration; > - gdbarch/language dispatching > - exception handling > - use of unions to emulate polymorphism; > - etc, etc, etc. Writing several different versions of object-oriented C to implement these features doesn't make gdb easier to debug or extend. > So again, the proposal that was put on the table a long time ago > was that some specific features of C++ be used in order to simplify > certain areas of GDB's code. The pro-C++ camps has, in my opinion, > successfully shown how C++ was going to help. The specific arguments, > in my opinion, should be brought up again, and those specific arguments > should be discussed, rather than just discussing generalities about > how horrible C++ is. > >> All it requires is a few more short lines of explanatory design >> notes scattered through the code and clarity of thought. In many places, gdb comments and descriptions range from meaningless to useless. The internals document is far out of date. In many areas, it is difficult to understand why the code does the odd things it does. I'm not sure where "clarity of thought" would be applied. Working in gdb is not easy. It doesn't seem to be getting better. There are many changes which, IMO, would reverse this trend. One would be to rewrite the parts which are currently written in object oriented code with incomplete encapsulation with clear C++ classes and member functions. Several parts of gdb are overly complex and would benefit from refactoring and redesign. As parts are converted to C++, perhaps this would give the opportunity for a long overdue review of the design. There's been an argument that poorly written C++ code is the only possible outcome of converting gdb to C++. I don't think that this is the inevitable result. Developers can write good C or good C++, as well as poor C or poor C++. Especially with gdb maintainers' concerns for the quality of C++ code, I would expect that converting gdb to C++ would favor (if not demand) producing good C++ rather than just checking in anything submitted. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 13:16 ` Joel Brobecker 2012-04-06 14:43 ` Russell Shaw 2012-04-06 15:34 ` Michael Eager @ 2012-04-06 23:32 ` John Gilmore 2012-04-07 1:04 ` Robert Dewar ` (2 more replies) 2 siblings, 3 replies; 116+ messages in thread From: John Gilmore @ 2012-04-06 23:32 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb > And yet, that's exactly what we are doing: > - unit elaboration; > - gdbarch/language dispatching > - exception handling > - use of unions to emulate polymorphism; Writing modular programs is a good idea even if we don't do it in C++. I have heard it claimed that many techniques of modular programming were even invented before C++ existed - though that may be doubted. If people have the energy to rewrite large chunks of GDB, why argue about it? Go off and do it. It's free software -- you don't even have to start from scratch like GNU did. The world can always use a new debugger. You can make a politically correct debugger (pcdb?) with an identical interface but a C++ implementation under the hood. If it's better than GDB in the long run, maintainers will migrate to it, GDB will fall into disrepair, and GNU will adopt it. It's always easier to see how a completely paper design is cleaner than a piece of running code whose warts are in front of you. And it means you can respond to critics by saying, "See - you can't find any problems in our nonexistent code, you are just making generalized statements about the implementation language, which we should all ignore as irrelevant." By the time you actually get the new design working, it too will have compromises, bugs, and won't match its documentation. Then again, if you had put that prodigious energy into updating the original piece of running code, perhaps it would have fewer bugs, fewer compromises, and updated documentation. John PS: Which particular unions in gdb are you complaining about ("used to emulate polymorphism")? I grepped the sources, and see a bunch used in BFD, in SIM, and in GDB's expression parser. It seems to me that they are all used to unify storage and access to disparate types of elements in a list or array -- not to make or fake polymorphism. This is what unions were designed for. Did I miss some corner where unions are cowering under the lash of abuse? PPS: What is "unit elaboration" and what does that have to do with GDB? All I can find from a quick web search is that it has something to do with Ada. Perhaps other languages don't do it -- or have another name for it. "Linking"? Are you sure we shouldn't rewrite bits of GDB in Ada instead of C++? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 23:32 ` John Gilmore @ 2012-04-07 1:04 ` Robert Dewar 2012-04-07 1:52 ` Thomas Dineen 2012-04-07 16:54 ` Michael Eager 2012-04-09 23:59 ` Stan Shebs 2 siblings, 1 reply; 116+ messages in thread From: Robert Dewar @ 2012-04-07 1:04 UTC (permalink / raw) To: John Gilmore; +Cc: Joel Brobecker, gdb On 4/6/2012 7:32 PM, John Gilmore wrote: >> And yet, that's exactly what we are doing: >> - unit elaboration; >> - gdbarch/language dispatching >> - exception handling >> - use of unions to emulate polymorphism; > > Writing modular programs is a good idea even if we don't do it in C++. > I have heard it claimed that many techniques of modular programming > were even invented before C++ existed - though that may be doubted. Doubted by whom? Certainly not by anyone with any awareness of the history of programming languages. The notions of modular programming existed LONG LONG before C++ was invented and are represented in many programming languages! Next someone will be thinking that C++ invented object oriented programming :-) > PPS: What is "unit elaboration" and what does that have to do with > GDB? All I can find from a quick web search is that it has something > to do with Ada. Perhaps other languages don't do it -- or have > another name for it. "Linking"? Are you sure we shouldn't rewrite > bits of GDB in Ada instead of C++? :-) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-07 1:04 ` Robert Dewar @ 2012-04-07 1:52 ` Thomas Dineen 0 siblings, 0 replies; 116+ messages in thread From: Thomas Dineen @ 2012-04-07 1:52 UTC (permalink / raw) To: gdb Gentle People: Re: History of programming languages: Who is the mother of modular programming? Do you believe that modular programming began with invention of the computer subroutine? If Yes then here is a tidbit from a class on patents that I took years ago: Who first patented the computer subroutine? Answer: Mary Wollstonecraft Bancroft in Brittan in or around 1865!!! Working on mechanical calculating machines! Mary's aunt is considered the mother of science fiction! Why? Mary's great aunt is considered the mother of the women's rights movement! Why? Mary's great uncle is considered the father of the anarchy movement? Why? An interesting family! Happy Easter, and in respect for the holidays be kind to each other! Thomas Dineen On 4/6/2012 6:03 PM, Robert Dewar wrote: > On 4/6/2012 7:32 PM, John Gilmore wrote: >>> And yet, that's exactly what we are doing: >>> - unit elaboration; >>> - gdbarch/language dispatching >>> - exception handling >>> - use of unions to emulate polymorphism; >> >> Writing modular programs is a good idea even if we don't do it in C++. >> I have heard it claimed that many techniques of modular programming >> were even invented before C++ existed - though that may be doubted. > > Doubted by whom? Certainly not by anyone with any awareness of the > history of programming languages. The notions of modular programming > existed LONG LONG before C++ was invented and are represented in > many programming languages! Next someone will be thinking that C++ > invented object oriented programming :-) > >> PPS: What is "unit elaboration" and what does that have to do with >> GDB? All I can find from a quick web search is that it has something >> to do with Ada. Perhaps other languages don't do it -- or have >> another name for it. "Linking"? Are you sure we shouldn't rewrite >> bits of GDB in Ada instead of C++? > > :-) > > ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 23:32 ` John Gilmore 2012-04-07 1:04 ` Robert Dewar @ 2012-04-07 16:54 ` Michael Eager 2012-04-09 23:59 ` Stan Shebs 2 siblings, 0 replies; 116+ messages in thread From: Michael Eager @ 2012-04-07 16:54 UTC (permalink / raw) To: gdb On 04/06/2012 04:32 PM, John Gilmore wrote: >> And yet, that's exactly what we are doing: >> - unit elaboration; >> - gdbarch/language dispatching >> - exception handling >> - use of unions to emulate polymorphism; > > Writing modular programs is a good idea even if we don't do it in C++. > I have heard it claimed that many techniques of modular programming > were even invented before C++ existed - though that may be doubted. If a discussion about the design of C++ adds little to the discussion about converting gdb to C++, I think that discussing the origins of modular or object-oriented programming offers even less. > If people have the energy to rewrite large chunks of GDB, why argue > about it? Go off and do it. It's free software -- you don't even > have to start from scratch like GNU did. The world can always use a > new debugger. You can make a politically correct debugger (pcdb?) > with an identical interface but a C++ implementation under the hood. > If it's better than GDB in the long run, maintainers will migrate to > it, GDB will fall into disrepair, and GNU will adopt it. That is actually not that bad an idea. This isn't a matter of political correctness, but one of technical merit. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++? Not. 2012-04-06 23:32 ` John Gilmore 2012-04-07 1:04 ` Robert Dewar 2012-04-07 16:54 ` Michael Eager @ 2012-04-09 23:59 ` Stan Shebs 2 siblings, 0 replies; 116+ messages in thread From: Stan Shebs @ 2012-04-09 23:59 UTC (permalink / raw) To: gdb On 4/6/12 4:32 PM, John Gilmore wrote: > > If people have the energy to rewrite large chunks of GDB, why argue > about it? Go off and do it. It's free software -- you don't even > have to start from scratch like GNU did. The world can always use a > new debugger. You can make a politically correct debugger (pcdb?) > with an identical interface but a C++ implementation under the hood. > If it's better than GDB in the long run, maintainers will migrate to > it, GDB will fall into disrepair, and GNU will adopt it. > > My initial reaction on reading this was "oh that bomb-thrower Gilmore is at it again", but upon rereading, I'm not sure whether you're being serious, or maybe a little tongue-in-cheek. In any case, one of the key underlying motivations for the C++ plan is that we *don't* have the energy to rewrite large chunks of GDB, nor to start over from scratch. (We delegated that to the LLVM folks. :-) ) Instead, we need to look for ways to keep growth under control, or to simplify things. For instance, these days we're much more likely to delete bits of code that are not in current use, even if one could imagine them being helpful in some future scenario. Another way to simplify the code is to offload work to the compiler. Anybody that's known me for any length of time knows that I'm not a big fan of C++, but even I have to admit there are some things that can be done better in C++ than in C, such as compiler-checked exception handling. Also, it's not like we're working in a vacuum - our friends in GCC-land have done a lot to provide good C++ functionality, and I know that they would be happy to help us make effective use of C++ in GDB. Stan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-04 20:48 ` Tom Tromey 2012-04-04 21:55 ` Mark Kettenis @ 2012-04-05 0:22 ` asmwarrior 2012-04-09 18:41 ` Pedro Alves ` (2 subsequent siblings) 4 siblings, 0 replies; 116+ messages in thread From: asmwarrior @ 2012-04-05 0:22 UTC (permalink / raw) To: gdb On 2012-4-5 4:47, Tom Tromey wrote: > My view is that GDB is already written in a poor cousin of C++. > Nearly every feature that people hate about C++ is already in use in > GDB. This list is not exhaustive, just informational: > > * Subclasses. See general_symbol_info. struct value and struct type > would be improved by them. > > * Virtual functions. gdbarch, languages, and values all use these. > > * Overloaded functions. Anywhere you see a _1 suffix. > > * Templates. Both observers and VEC are templates. > > * Exceptions. Used ubiquitously. > > * RAII. Cleanups, but they are dynamic and more error-prone. > > * Even global constructors -- init.c. > > In most cases, GDB's implementation of these features is inferior to > that of the C++ compiler. Agreed. Simulate C++ feature in plain C style macros and callbacks are boring and hard to maintain. BTW: There are some discussion about C++ in GCC 4.8, maybe, your gdb administrators (committee) can also give a plane. Asmwarrior Code::Blocks developer ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-04 20:48 ` Tom Tromey 2012-04-04 21:55 ` Mark Kettenis 2012-04-05 0:22 ` Will therefore GDB utilize C++ or not? asmwarrior @ 2012-04-09 18:41 ` Pedro Alves 2012-04-09 19:05 ` Jan Kratochvil ` (4 more replies) 2012-04-09 23:23 ` Stan Shebs 2012-04-19 8:43 ` Yao Qi 4 siblings, 5 replies; 116+ messages in thread From: Pedro Alves @ 2012-04-09 18:41 UTC (permalink / raw) To: Tom Tromey; +Cc: Jan Kratochvil, gdb If you asked me not too long ago, I'd have been strongly in favor of C++. However, that is no longer the case. I'm now pending towards "no C++". Indeed, gdbserver would need to remain pure C, and likewise any code shared between gdbserver and gdb should have to be kept as such. This is important, because we want gdbserver to be usable in #1, resource constrained scenarios where the C++ dependency would be unacceptable. We don't want there to need to be other gdbserver-like programs specialized for such environments, and gdbserver to be usable only on bigger machines. We want gdbserver to run everywhere. And #2, the debugger is one of the first programs that is desirable to get running on a new system/board. Usually you get C going much sooner than C++. This, above, mainly #1, made me spend the last few days thinking about the "to C++ or not to C++" dilema, and I ended up concluding that C++ may not be a good idea afterall. I'm very wary that introducing C++ will make it increasingly difficult to share between the C++ and C parts. Currently not that much is shared between gdb and gdbserver, but it is long desired, and in actually in this year's plan to merge gdb's and gdbserver's backends (am I am actively working on this. See <http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity>). Another set of code that could also be shared, and thus would need to remain C is the ser*.c files. The ser_ops vector is one of those bits that would be "obvious" candidates for turning into C++ classes, but given the desire to reuse, it would need to stay C. The event-loop.c file is yet another thing. It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c. There goes another use for C++ classes. The "monitor foo" commands are implemented completely by the target. E.g., try "monitor help" in gdbserver. GDBserver's implementation of monitor commands is ad hoc. This mechanism isn't transparent to GDB and users. E.g., completion can't work with these commands. I have desired before to rip out GDB's command registration machinery under cli/, making it more modular, and reusing it in GDBserver. There goes another big potential user for C++-fication. And then, there's the exceptions support. GDBserver's current error handling is like GDB's was 10 years ago. There's a simple setjmp at the top level, and any error longjmp's there. The debugging session tends to gets broken when an "error" happens This is even more likely to happen with multi-inferior debugging. As such, and with the gdb -> gdbserver backend merging in mind, it'd be desirable to make gdbserver's backends use GDB's TRY_CATCH and friends too. GDB's backends already do... Now, if parts of GDB are written in C++, which will be made to throw/catch C++ exceptions, we end up with the case that we need to wrap cross-language calls in both directions, in order to bridge/wrap the incompatible exceptions mechanisms. IMO, this is a _worse_ state than having the whole of the GDB core in C, and having everything and everyone speak the same language. The target_ops vector is yet another candidate for sharing between native gdb and gdbserver. Currently in gdbserver, linux-low.c calls into thread_db.c directly, while in the native debugger the flow is reversed. Even if the target vector ends up being replaced by some other form of chaining, it'd be very desirable to use the same mechanism in either the native debugger or gdbserver. So this means that the target_ops vector is something else that is probably not good to consider converting to C++ classes, although it always shows up high on the list of candidates. And I'm sure I could come up with other examples of things that would be nice C++ classes, but, we better not make them so. We can't really tell at this point what could or not be C++-ified freely, and I'd hate it to see some code converted to C++, only to end up needing to fork it and convert it to C down the road. Or worse, rewrite it from scratch. (On a sidenote: I get the impression from some that C++ would be mostly useful for the stronger static typing, but I can't help finding it in contrast with the simultaneous push of some of GDB functionality towards being implemented in python, with duck typing and all, which people are happy with. One (uninvestigated) idea I had was to take a look at Linux's sparse tool for catching issues like the "offsets" case that led to this thread.) There's also the issue with in-process code, which is also desirable to remain as C code. Latest developments push towards having debugger code run _within_ the inferior. Witness gdbserver's current IPA (in-process agent; libinproctrace.so), which has a lot of coupling in its implementation (and a lot of code shared), and a bunch of code shared with gdbserver. We can't predict which bits of GDB will we want to be able to reuse in GDBserver or an IPA, but I do believe that we will be considering it (reuse something more) the future. So all in all, I believe that in a C++ world, GDB's "C++ in C" wouldn't really go away; it would end up still being prominent, not as hidden as libbfd or other dependencies. Not hidden enough that we could just tuck it under the carpet. I worry that this actually makes it _worse_ for new contributers, who will need to learn about GDB's C idiomatic usage, and whatever new C++ idiomatic usage GDB would end up with. With that, and the worry about the new source of trouble and bugs and confusion that it would be the bridging between the parts written in the different languages, I do believe we're better off staying in C land, at least for a couple years more. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 18:41 ` Pedro Alves @ 2012-04-09 19:05 ` Jan Kratochvil 2012-04-09 19:49 ` Pedro Alves 2012-04-10 0:23 ` Yao Qi ` (3 subsequent siblings) 4 siblings, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-04-09 19:05 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: > Indeed, gdbserver would need to remain pure C, [...] > This is important, because we want gdbserver to be usable > in #1, resource constrained scenarios where the C++ dependency would > be unacceptable. We don't want there to need to be other gdbserver-like > programs specialized for such environments, and gdbserver to be usable only > on bigger machines. We want gdbserver to run everywhere. And #2, the debugger > is one of the first programs that is desirable to get running on a new > system/board. Usually you get C going much sooner than C++. While it was said before gdbserver should stay in C I did not see it long-term maintainable - due to the code sharing goals. While I wanted to simplify the talk excluding gdbserver first we can talk even about C++ization of gdbserver. Which specific platforms do you talk about which is UNIX compatible (=FSF gdbserver compatible, not just an embedded stub) and cannot run C++ programs? (*) Please give examples of viable platforms with future development. (*) The smallest device I know about is SIM card - and it runs Java (Card) VM, therefore more heavy environment than C++. > The event-loop.c file is yet another thing. > It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c. > There goes another use for C++ classes. The mail lists all the code parts which cannot be C++ized. I do not find that too interesting. I find interesting code parts which can be C++ized - such as anything about symbols/types outside of gdbserver. > (On a sidenote: I get the impression from some that C++ would be mostly > useful for the stronger static typing, Not just that one, std::string vs. cleanups vs. exceptions are even more wanted (by me); just static typing (probably) cannot be done without C++, the other parts are still being fixed up without C++. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 19:05 ` Jan Kratochvil @ 2012-04-09 19:49 ` Pedro Alves 2012-04-09 20:15 ` Paul Smith ` (3 more replies) 0 siblings, 4 replies; 116+ messages in thread From: Pedro Alves @ 2012-04-09 19:49 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Tom Tromey, gdb On 04/09/2012 08:05 PM, Jan Kratochvil wrote: > On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: >> Indeed, gdbserver would need to remain pure C, > [...] >> This is important, because we want gdbserver to be usable >> in #1, resource constrained scenarios where the C++ dependency would >> be unacceptable. We don't want there to need to be other gdbserver-like >> programs specialized for such environments, and gdbserver to be usable only >> on bigger machines. We want gdbserver to run everywhere. And #2, the debugger >> is one of the first programs that is desirable to get running on a new >> system/board. Usually you get C going much sooner than C++. > > While it was said before gdbserver should stay in C I did not see it long-term > maintainable - due to the code sharing goals. I do. > While I wanted to simplify the > talk excluding gdbserver first we can talk even about C++ization of gdbserver. > > Which specific platforms do you talk about which is UNIX compatible (=FSF > gdbserver compatible, not just an embedded stub) and cannot run C++ programs? > (*) Please give examples of viable platforms with future development. GNU's not UNIX. Haven't you heard? And why do you keep excluding embedded things? This is a recurrent point you raise in several discussions. Haven't you noticed the trend towards mobile computing? Even Red Hat has business in the embedded world since a long long time (GNUPro and services). Even Android/Bionic doesn't support C++ exceptions (not sure if it doesn't in recent versions or not). I don't even need to leave my office to find such a system. $ssh 192.168.0.253 [pedro@NAS][~] >ls /usr/lib/libstd* ls: cannot access /usr/lib/libstdc*: No such file or directory > uname -a Linux NAS 2.6.24.4 #1 Tue Feb 10 11:00:22 GMT 2009 armv5tejl unknown >> The event-loop.c file is yet another thing. >> It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c. >> There goes another use for C++ classes. > > The mail lists all the code parts which cannot be C++ized. I do not find that > too interesting. It explained that many core parts of GDB should stay in C. Which served to raise awareness that converting just a few parts to avoid a few bugs and making things neater here and there has a lot of potential for making things worse. I find interesting code parts which can be C++ized - such as > anything about symbols/types outside of gdbserver. It is very much not clear to me that it is worth the pain (that I tried to show we will end up with) to bring in C++ for this. Symbol/types even are long lived objects, it's not common at all to need to worry about leaks (RAII/exceptions) here. And all we have are simple hierarchies. As much as I like C++, C does quite fine here too. The language it is written in is not the problem with our symbol tables. > > >> (On a sidenote: I get the impression from some that C++ would be mostly >> useful for the stronger static typing, > > Not just that one, std::string vs. cleanups vs. exceptions are even more > wanted (by me); just static typing (probably) cannot be done without C++, > the other parts are still being fixed up without C++. Sure, there will always be bugs. C++ doesn't magically make all bugs go away. Even RAII is not _that_ different from cleanups. We still need to have a way to tell the RAII wrapper objects to stop managing whatever they're managing, for instance. And with C++98/03, we have to write these things out of line, like cleanups too. What I'm saying is that our C mechanisms work. There is no need to rush to replace them. We should consider this very very carefully, not just flip just because. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 19:49 ` Pedro Alves @ 2012-04-09 20:15 ` Paul Smith 2012-04-12 20:06 ` Daniel Jacobowitz ` (2 subsequent siblings) 3 siblings, 0 replies; 116+ messages in thread From: Paul Smith @ 2012-04-09 20:15 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, Tom Tromey, gdb On Mon, 2012-04-09 at 20:48 +0100, Pedro Alves wrote: > I don't even need to leave my office to find such a system. > > $ssh 192.168.0.253 > [pedro@NAS][~] > >ls /usr/lib/libstd* > ls: cannot access /usr/lib/libstdc*: No such file or directory I personally have no strong feelings about this either way but note the above is not an argument against C++ on embedded systems. On many of the systems I use I statically link libstdc++ with at least some programs; this is well-supported (by GCC at least) and IMO a quite reasonable solution for utilities such as gdbserver. The question is not whether systems provide a C++ userspace environment by default (such as libstdc++): static linking can take care of that very neatly. The question is how many of them WOULD be able to run gdbserver in C, but NOT able to run gdbserver in C++ (from a resource point of view). ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 19:49 ` Pedro Alves 2012-04-09 20:15 ` Paul Smith @ 2012-04-12 20:06 ` Daniel Jacobowitz 2012-04-12 21:28 ` Paul_Koning ` (2 more replies) 2012-04-16 6:55 ` Jan Kratochvil 2012-04-18 20:25 ` Tom Tromey 3 siblings, 3 replies; 116+ messages in thread From: Daniel Jacobowitz @ 2012-04-12 20:06 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, Tom Tromey, gdb On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves <palves@redhat.com> wrote: > On 04/09/2012 08:05 PM, Jan Kratochvil wrote: > >> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: >>> Indeed, gdbserver would need to remain pure C, >> [...] >>> This is important, because we want gdbserver to be usable >>> in #1, resource constrained scenarios where the C++ dependency would >>> be unacceptable. We don't want there to need to be other gdbserver-like >>> programs specialized for such environments, and gdbserver to be usable only >>> on bigger machines. We want gdbserver to run everywhere. And #2, the debugger >>> is one of the first programs that is desirable to get running on a new >>> system/board. Usually you get C going much sooner than C++. The more things we add to gdbserver, the less I think it meets the goal of "simple, light-weight target agent". I resisted code sharing with GDB for a long time. If the consensus nowadays is that code sharing is the way to go, then I think it behooves someone to figure out the needs of a modern light-weight target agent that's a lot smaller than gdbserver. Yes, multiprocess debugging with gdbserver is an awesome development. No, you don't need it in the stage of system bringup where you don't have C++, if you're planning to have C++ eventually. So I think there's room for a potential C++ gdbserver and a small C gdbserver. How did I end up being the curmudgeon? I'm confused. -- Thanks, Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* RE: Will therefore GDB utilize C++ or not? 2012-04-12 20:06 ` Daniel Jacobowitz @ 2012-04-12 21:28 ` Paul_Koning 2012-04-13 0:04 ` Doug Evans 2012-04-18 14:08 ` Pedro Alves 2 siblings, 0 replies; 116+ messages in thread From: Paul_Koning @ 2012-04-12 21:28 UTC (permalink / raw) To: daniel.jacobowitz, palves; +Cc: jan.kratochvil, tromey, gdb Yes, it's good to be watchful for code bloat on gdbserver. But a very big difference between it and gdb is that the symbol tables are at the gdb end. In our case, that's the main reason we use gdbserver. It would be tolerable for the executable to be bigger, but we don't have space for many of the inferior's symbol tables on the target system. paul -----Original Message----- From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Daniel Jacobowitz Sent: Thursday, April 12, 2012 4:06 PM To: Pedro Alves Cc: Jan Kratochvil; Tom Tromey; gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves <palves@redhat.com> wrote: > On 04/09/2012 08:05 PM, Jan Kratochvil wrote: > >> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: >>> Indeed, gdbserver would need to remain pure C, >> [...] >>> This is important, because we want gdbserver to be usable in #1, >>> resource constrained scenarios where the C++ dependency would be >>> unacceptable. We don't want there to need to be other >>> gdbserver-like programs specialized for such environments, and >>> gdbserver to be usable only on bigger machines. We want gdbserver >>> to run everywhere. And #2, the debugger is one of the first >>> programs that is desirable to get running on a new system/board. Usually you get C going much sooner than C++. The more things we add to gdbserver, the less I think it meets the goal of "simple, light-weight target agent". I resisted code sharing with GDB for a long time. If the consensus nowadays is that code sharing is the way to go, then I think it behooves someone to figure out the needs of a modern light-weight target agent that's a lot smaller than gdbserver. Yes, multiprocess debugging with gdbserver is an awesome development. No, you don't need it in the stage of system bringup where you don't have C++, if you're planning to have C++ eventually. So I think there's room for a potential C++ gdbserver and a small C gdbserver. How did I end up being the curmudgeon? I'm confused. -- Thanks, Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-12 20:06 ` Daniel Jacobowitz 2012-04-12 21:28 ` Paul_Koning @ 2012-04-13 0:04 ` Doug Evans 2012-04-18 14:10 ` Pedro Alves 2012-04-18 20:27 ` Tom Tromey 2012-04-18 14:08 ` Pedro Alves 2 siblings, 2 replies; 116+ messages in thread From: Doug Evans @ 2012-04-13 0:04 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Pedro Alves, Jan Kratochvil, Tom Tromey, gdb On Thu, Apr 12, 2012 at 1:06 PM, Daniel Jacobowitz <daniel.jacobowitz@gmail.com> wrote: > The more things we add to gdbserver, the less I think it meets the > goal of "simple, light-weight target agent". I resisted code sharing > with GDB for a long time. If the consensus nowadays is that code > sharing is the way to go, then I think it behooves someone to figure > out the needs of a modern light-weight target agent that's a lot > smaller than gdbserver. > > Yes, multiprocess debugging with gdbserver is an awesome development. > No, you don't need it in the stage of system bringup where you don't > have C++, if you're planning to have C++ eventually. So I think > there's room for a potential C++ gdbserver and a small C gdbserver. [filing for reference sake] I'd (ultimately) like to see gdb and gdbserver built up out of a set of, umm, libraries ("We need more libraries!"). Exporting the functionality of the libraries to scripting languages (e.g., python) through these libraries would involve more of a C API than C++. With said partitioning of functionality, it shouldn't be that hard to have either a small and simple gdbserver or a large and feature-rich gdbserver. [side question: Do people that want a small embedded-system-like gdbserver, also want it to have same features as the the massively feature rich gdbserver of a non-embedded-system gdbserver? I'd expect that they're ok that the overarching need of smallness precluding some, umm, bloatware. :-)] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-13 0:04 ` Doug Evans @ 2012-04-18 14:10 ` Pedro Alves 2012-04-18 20:27 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Pedro Alves @ 2012-04-18 14:10 UTC (permalink / raw) To: Doug Evans Cc: Daniel Jacobowitz, Pedro Alves, Jan Kratochvil, Tom Tromey, gdb On 04/13/2012 01:04 AM, Doug Evans wrote: > On Thu, Apr 12, 2012 at 1:06 PM, Daniel Jacobowitz > <daniel.jacobowitz@gmail.com> wrote: >> The more things we add to gdbserver, the less I think it meets the >> goal of "simple, light-weight target agent". I resisted code sharing >> with GDB for a long time. If the consensus nowadays is that code >> sharing is the way to go, then I think it behooves someone to figure >> out the needs of a modern light-weight target agent that's a lot >> smaller than gdbserver. >> >> Yes, multiprocess debugging with gdbserver is an awesome development. >> No, you don't need it in the stage of system bringup where you don't >> have C++, if you're planning to have C++ eventually. So I think >> there's room for a potential C++ gdbserver and a small C gdbserver. > > [filing for reference sake] > > I'd (ultimately) like to see gdb and gdbserver built up out of a set > of, umm, libraries ("We need more libraries!"). I'm aiming torwards making the gdbserver backends be a library that is reused by both gdb and gdbserver. Gotta start somewhere. > Exporting the functionality of the libraries to scripting languages > (e.g., python) through these libraries would involve more of a C API > than C++. > > With said partitioning of functionality, it shouldn't be that hard to > have either a small and simple gdbserver or a large and feature-rich > gdbserver. Exactly. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-13 0:04 ` Doug Evans 2012-04-18 14:10 ` Pedro Alves @ 2012-04-18 20:27 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-04-18 20:27 UTC (permalink / raw) To: Doug Evans; +Cc: Daniel Jacobowitz, Pedro Alves, Jan Kratochvil, gdb >>>>> "Doug" == Doug Evans <dje@google.com> writes: Doug> Exporting the functionality of the libraries to scripting languages Doug> (e.g., python) through these libraries would involve more of a C API Doug> than C++. I think you can wrap a C++ library in Python just fine, especially since we're writing all the bindings manually anyhow. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-12 20:06 ` Daniel Jacobowitz 2012-04-12 21:28 ` Paul_Koning 2012-04-13 0:04 ` Doug Evans @ 2012-04-18 14:08 ` Pedro Alves 2012-04-21 17:24 ` Daniel Jacobowitz 2 siblings, 1 reply; 116+ messages in thread From: Pedro Alves @ 2012-04-18 14:08 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Pedro Alves, Jan Kratochvil, Tom Tromey, gdb On 04/12/2012 09:06 PM, Daniel Jacobowitz wrote: > On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves <palves@redhat.com> wrote: >> On 04/09/2012 08:05 PM, Jan Kratochvil wrote: >> >>> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: >>>> Indeed, gdbserver would need to remain pure C, >>> [...] >>>> This is important, because we want gdbserver to be usable >>>> in #1, resource constrained scenarios where the C++ dependency would >>>> be unacceptable. We don't want there to need to be other gdbserver-like >>>> programs specialized for such environments, and gdbserver to be usable only >>>> on bigger machines. We want gdbserver to run everywhere. And #2, the debugger >>>> is one of the first programs that is desirable to get running on a new >>>> system/board. Usually you get C going much sooner than C++. > > The more things we add to gdbserver, the less I think it meets the > goal of "simple, light-weight target agent". Most things we add to gdbserver are optional. E.g., tracepoints, and the accelerated DSO list reading. It'd be simple to add a --bare-bones configure switch that disabled all the optional features. > Yes, multiprocess debugging with gdbserver is an awesome development. > No, you don't need it in the stage of system bringup where you don't > have C++, if you're planning to have C++ eventually. I don't think multiprocess debugging adds much in terms of code size. It touches a lot, because it paremetrizes things with additional structures instead of globals, but mostly, that's it. A lot of code needed to _change_, not be added. > So I think > there's room for a potential C++ gdbserver and a small C gdbserver. Seriously, I'd very very much like to fuse GDB's and GDBserver's backends, to eliminate the duplication, which really gets in the way. I should know; adding multi-process and non-stop to gdbserver wasn't that much accelerated from having added it to gdb itself, given how the codebases are similar, yet so different. So on order to remove the duplication, we'd end up with _two_ gdbservers, written in different languages, each with its own bugs and need for maintenance, adding of new arch ports, etc.? Doesn't seem like a net win to me. :-) -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 14:08 ` Pedro Alves @ 2012-04-21 17:24 ` Daniel Jacobowitz 0 siblings, 0 replies; 116+ messages in thread From: Daniel Jacobowitz @ 2012-04-21 17:24 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, Tom Tromey, gdb On Wed, Apr 18, 2012 at 10:07 AM, Pedro Alves <palves@redhat.com> wrote: > On 04/12/2012 09:06 PM, Daniel Jacobowitz wrote: >> The more things we add to gdbserver, the less I think it meets the >> goal of "simple, light-weight target agent". > > > Most things we add to gdbserver are optional. E.g., tracepoints, and the > accelerated DSO list reading. It'd be simple to add a --bare-bones configure > switch that disabled all the optional features. A complex program with optional features doesn't get simpler just because the optional bits are turned off. The more configuration options there are, the less likely any of them work. That's my position. >> Yes, multiprocess debugging with gdbserver is an awesome development. > >> No, you don't need it in the stage of system bringup where you don't >> have C++, if you're planning to have C++ eventually. > > > I don't think multiprocess debugging adds much in terms of > code size. It touches a lot, because it paremetrizes things with > additional structures instead of globals, but mostly, that's it. > A lot of code needed to _change_, not be added. A lot of code needs to be *more complicated* because of it. That's what I think is the mistake. I'll even argue that multi-threaded support with a C++ dependency is basically OK. If we're going to have trouble because of uclibc or Android or LynxOS, then we can either change the minimal feature set supported by the C version or we can make the necessary runtime work on the bigger platforms. I really don't think it's infeasible. I don't think that there's a good reason to restrict the progress of the larger program because we need a small program too. > >> So I think >> there's room for a potential C++ gdbserver and a small C gdbserver. > > Seriously, I'd very very much like to fuse GDB's and GDBserver's backends, > to eliminate the duplication, which really gets in the way. I should know; > adding multi-process and non-stop to gdbserver wasn't that much accelerated > from having added it to gdb itself, given how the codebases are similar, yet > so different. > So on order to remove the duplication, we'd end up with _two_ gdbservers, written > in different languages, each with its own bugs and need for maintenance, adding of > new arch ports, etc.? Doesn't seem like a net win to me. :-) Does seem like a win to me. I think people overestimate how complicated a basic gdbserver port is. The bits that are hard to figure out you have to figure out for GDB anyway, if you're going to bother with GDB. Especially if threading ends up above the language bar. -- Thanks, Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 19:49 ` Pedro Alves 2012-04-09 20:15 ` Paul Smith 2012-04-12 20:06 ` Daniel Jacobowitz @ 2012-04-16 6:55 ` Jan Kratochvil 2012-04-18 14:11 ` Pedro Alves 2012-04-18 20:31 ` Will therefore GDB utilize C++ or not? Tom Tromey 2012-04-18 20:25 ` Tom Tromey 3 siblings, 2 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-04-16 6:55 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Mon, 09 Apr 2012 21:48:57 +0200, Pedro Alves wrote: > Symbol/types even are long lived objects, it's not common at all to need to > worry about leaks (RAII/exceptions) here. They are and they should not be, this is what archer-jankratochvil-vla with dynamic types is there for and which are not well maintainable without C++. There was Tom's reference counting implementation which I found fragile + complicated so I wrote a custom garbage collector [patch 0/8] Types Garbage Collector (for VLA+Python) http://sourceware.org/ml/gdb-patches/2009-05/msg00543.html but it was sure also a wheel reinvention, with RAII it would be all easier (sure not automagical but some parts of reference counting done automatically). > On 04/09/2012 08:05 PM, Jan Kratochvil wrote: > > Not just that one, std::string vs. cleanups vs. exceptions are even more > > wanted (by me); just static typing (probably) cannot be done without C++, > > the other parts are still being fixed up without C++. > > Sure, there will always be bugs. C++ doesn't magically make all bugs go away. > Even RAII is not _that_ different from cleanups. It is very different, for the very common std::string one does not even have to start thinking about any cleanups. If GDB should stay with C then OK (although FYI I am not so in favor of it). But then it should be real C - therefore without GDB cleanups, without GDB TRY_CATCH etc. etc., proper C code returning error codes from each function and each caller checking it and doing all the local cleanups by hand. I do not know any larger project in C with proper error checking, there are: * Linux kernel lacks proper error reporting, common unclear EPERM from ptrace for 100+ different reasons is a great illustration. At most it uses printk, not too good and even reusable for GDB. * GCC uses an extra garbage collector with terrible markers in C code, that is also not a good example to follow. I do not remember / know how they resolve error reporting / exceptions in GCC. * There sure are more larger projects in plain C, but which ones? Daniel's idea of having two - light (C, separate code) + heavy (C++, GDB sharing code) - gdbservers I had on my mind myself before his post. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-16 6:55 ` Jan Kratochvil @ 2012-04-18 14:11 ` Pedro Alves 2012-04-18 15:16 ` Jan Kratochvil 2012-04-18 20:31 ` Will therefore GDB utilize C++ or not? Tom Tromey 1 sibling, 1 reply; 116+ messages in thread From: Pedro Alves @ 2012-04-18 14:11 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, Tom Tromey, gdb On 04/16/2012 07:54 AM, Jan Kratochvil wrote: > On Mon, 09 Apr 2012 21:48:57 +0200, Pedro Alves wrote: >> Symbol/types even are long lived objects, it's not common at all to need to >> worry about leaks (RAII/exceptions) here. > > They are and they should not be, this is what archer-jankratochvil-vla with > dynamic types is there for and which are not well maintainable without C++. I don't even know how to begin to respond to that. :-) The symbols side is perhaps the part of a debugger that needs the most care about memory, and where you'll most likely to see the need for POD types, and lower level handling of memory, like the bcache. > If GDB should stay with C then OK (although FYI I am not so in favor of it). > But then it should be real C - therefore without GDB cleanups, without GDB > TRY_CATCH etc. etc., proper C code returning error codes from each function > and each caller checking it and doing all the local cleanups by hand. This is going backwards, and can't really be a serious proposal. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 14:11 ` Pedro Alves @ 2012-04-18 15:16 ` Jan Kratochvil 2012-04-18 15:28 ` Pedro Alves 2012-04-18 19:18 ` Will C++ proponents spend 20 minutes to try what they're proposing? John Gilmore 0 siblings, 2 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-04-18 15:16 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Wed, 18 Apr 2012 16:10:58 +0200, Pedro Alves wrote: > On 04/16/2012 07:54 AM, Jan Kratochvil wrote: > > They are and they should not be, this is what archer-jankratochvil-vla with > > dynamic types is there for and which are not well maintainable without C++. > > I don't even know how to begin to respond to that. :-) The symbols side is perhaps > the part of a debugger that needs the most care about memory, and where you'll > most likely to see the need for POD types, and lower level handling of > memory, like the bcache. This is the current wrong approach where (a) CUs are expanded fully, not just the one or few symbols one started expanding that CU for. (b) CUs are expanded needlessly, such as during <tab>-expansion, there are more cases I did not analyze. And then with 99% of symbols not needed at all one tries to optimize every bit out of each symbol to make the 100% total size bearable... Just because everything is statically accessed and the expansion cannot be easily done on-demand when one accesses the fields by using getters everywhere. I can't believe we do not agree on such basic way forward. As one of the many examples the current main_type is unbelievable, I would not think it is possible to create something so bizarre, it could be sure fixed by redesigning it even in C (one big union with all fields specific per type and not just generic fields each overloaded differently for each type). But then we would end up with GTK - it has the right design but it is still C++-in-C, I hope everyone agrees GTK is wrong. Regards, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 15:16 ` Jan Kratochvil @ 2012-04-18 15:28 ` Pedro Alves 2012-04-18 15:54 ` Jan Kratochvil 2012-04-18 19:18 ` Will C++ proponents spend 20 minutes to try what they're proposing? John Gilmore 1 sibling, 1 reply; 116+ messages in thread From: Pedro Alves @ 2012-04-18 15:28 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Tom Tromey, gdb On 04/18/2012 04:15 PM, Jan Kratochvil wrote: > On Wed, 18 Apr 2012 16:10:58 +0200, Pedro Alves wrote: >> On 04/16/2012 07:54 AM, Jan Kratochvil wrote: >>> They are and they should not be, this is what archer-jankratochvil-vla with >>> dynamic types is there for and which are not well maintainable without C++. >> >> I don't even know how to begin to respond to that. :-) The symbols side is perhaps >> the part of a debugger that needs the most care about memory, and where you'll >> most likely to see the need for POD types, and lower level handling of >> memory, like the bcache. > > This is the current wrong approach where > (a) CUs are expanded fully, not just the one or few symbols one started > expanding that CU for. > (b) CUs are expanded needlessly, such as during <tab>-expansion, there are > more cases I did not analyze. > > And then with 99% of symbols not needed at all one tries to optimize every bit > out of each symbol to make the 100% total size bearable... You appear to be talking again about high level design choices that really doesn't have much to do with the language they're implemented in. Sure, C++ would make some things easier, but it also makes other objectives harder or impossible. It's a compromise. > Just because > everything is statically accessed and the expansion cannot be easily done > on-demand when one accesses the fields by using getters everywhere. I don't understand what you mean. Certainly adding the C++ getters would be as much work as adding C getters. It's not like C++ writes itself. Again, you don't have to convince me that C++ is nice. I know it is. I like it. I've written C++ for years and practically nothing else. ut I don't like the prospect of a fragmented GDB with important parts in C and others in C++, with all the same issues you don't like in C still in important and wide use. I loathe the idea of someone contributing some new code, and having to say "nice, but please rewrite it in C, because we may need it for X". If we stick to one language everywhere, in the net sum, there's less to learn for new comers. > I can't believe we do not agree on such basic way forward. > As one of the many examples the current main_type is unbelievable, I would not > think it is possible to create something so bizarre, it could be sure fixed by > redesigning it even in C (one big union with all fields specific per type and > not just generic fields each overloaded differently for each type). But then > we would end up with GTK - it has the right design but it is still C++-in-C, > I hope everyone agrees GTK is wrong. ... -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 15:28 ` Pedro Alves @ 2012-04-18 15:54 ` Jan Kratochvil 2012-04-18 16:01 ` Pedro Alves ` (3 more replies) 0 siblings, 4 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-04-18 15:54 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Wed, 18 Apr 2012 17:27:55 +0200, Pedro Alves wrote: > I don't like the prospect of a fragmented GDB with important parts in C and > others in C++, OK, we can therefore target only this problem. I do not think we should seriously code anything in C. Primarily one can argue there will be already some problem GDB itself will require C++ environment so that one can no longer run GDB in the early system bootstrap phases. I think this disadvantage everyone has already agreed with for the C++ benefits for GDB. So there remain only the very niche cases of bootstrapping system without C++ yet and having connected rich system with GDB so that one wants to use GDBSERVER. I believe some very simplistic C gdbserver can be used for such case. I admit I never bootstrapped such new system myself. I believe only few people in the world do so, AFAIK new architectures are no longer being created so commonly as before even for those few toolchain developers. Making GDB crashing for every GNU/Linux end-user developer just to make easier bootstrapping system for the few toolchain developers is IMNSHO not worth it. I do not repeat all the Bugs here leading to GDB crashes I get continuously from ABRT (bugreporting system) in Bugzilla due to missing automatic code sanity checking possible with C++. We can talk about the C gdbserver, I believe it can be forked from the current codebase and removed almost everything there, including threading support. But I do not have experience with new architectures bootstrapping myself. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 15:54 ` Jan Kratochvil @ 2012-04-18 16:01 ` Pedro Alves 2012-04-18 16:07 ` Joel Brobecker ` (2 subsequent siblings) 3 siblings, 0 replies; 116+ messages in thread From: Pedro Alves @ 2012-04-18 16:01 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, Tom Tromey, gdb On 04/18/2012 04:53 PM, Jan Kratochvil wrote: > On Wed, 18 Apr 2012 17:27:55 +0200, Pedro Alves wrote: >> I don't like the prospect of a fragmented GDB with important parts in C and >> others in C++, > > OK, we can therefore target only this problem. I do not think we should > seriously code anything in C. > Making GDB crashing for every GNU/Linux end-user developer just to make easier > bootstrapping system for the few toolchain developers is IMNSHO not worth it. Non sequitur. > We can talk about the C gdbserver, I believe it can be forked from the current > codebase and removed almost everything there, including threading support. > But I do not have experience with new architectures bootstrapping myself. I've already replied to the same point today, 2 times: http://sourceware.org/ml/gdb/2012-04/msg00113.html http://sourceware.org/ml/gdb/2012-04/msg00110.html -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 15:54 ` Jan Kratochvil 2012-04-18 16:01 ` Pedro Alves @ 2012-04-18 16:07 ` Joel Brobecker 2012-04-18 16:13 ` Jan Kratochvil 2012-04-18 20:36 ` Tom Tromey 2012-04-18 17:48 ` John Gilmore 2012-04-18 20:34 ` Will therefore GDB utilize C++ or not? Tom Tromey 3 siblings, 2 replies; 116+ messages in thread From: Joel Brobecker @ 2012-04-18 16:07 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, Tom Tromey, gdb > We can talk about the C gdbserver, I believe it can be forked from > the current codebase and removed almost everything there, including > threading support. But I do not have experience with new > architectures bootstrapping myself. I we are going to share GDBserver and GDB (understand making GDBserver a library that GDB uses), I do not think that having a forked copy of GDBserver in C is a good idea. I'd much rather we evaluate the concerns of linking with the C++ runtime, for instance. After reading the whole discussion, I think that there are not enough advantages outweighing the drawbacks for us to move to C++. Things may change in the future, but I also feel that there is too much resitance (within the group of GDB Maintainers) at this time, to make such a drastic change. I am a little bit surprised by that, since I thought only one or two of us had reservations, but clearly not so. -- Joel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 16:07 ` Joel Brobecker @ 2012-04-18 16:13 ` Jan Kratochvil 2012-04-18 16:23 ` Joel Brobecker 2012-04-18 20:36 ` Tom Tromey 1 sibling, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-04-18 16:13 UTC (permalink / raw) To: Joel Brobecker; +Cc: Pedro Alves, Tom Tromey, gdb On Wed, 18 Apr 2012 18:06:44 +0200, Joel Brobecker wrote: > Things may change in the future, What can change? C++ usage is already decreasing, most of the new development is in Java. If C++ is already not suitable it will never be. We should start discussing about moving to Java if C++ is not feasible now. This paragraph is not meant too seriously but I see no other possibily. Regards, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 16:13 ` Jan Kratochvil @ 2012-04-18 16:23 ` Joel Brobecker 2012-04-18 16:31 ` Joel Sherrill 0 siblings, 1 reply; 116+ messages in thread From: Joel Brobecker @ 2012-04-18 16:23 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, Tom Tromey, gdb > What can change? C++ usage is already decreasing, most of the new > development is in Java. If C++ is already not suitable it will never > be. Many things can change. Just one example: The constraints placed on GDB/GDBserver could change and lead to a more positive terrain for C++ adoption. Maybe, one day, the conditions will be right. Just not today. -- Joel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 16:23 ` Joel Brobecker @ 2012-04-18 16:31 ` Joel Sherrill 2012-04-18 16:50 ` Pedro Alves 0 siblings, 1 reply; 116+ messages in thread From: Joel Sherrill @ 2012-04-18 16:31 UTC (permalink / raw) To: Joel Brobecker; +Cc: Jan Kratochvil, Pedro Alves, Tom Tromey, gdb On 04/18/2012 11:22 AM, Joel Brobecker wrote: >> What can change? C++ usage is already decreasing, most of the new >> development is in Java. If C++ is already not suitable it will never >> be. > Many things can change. Just one example: The constraints placed > on GDB/GDBserver could change and lead to a more positive terrain > for C++ adoption. Maybe, one day, the conditions will be right. > Just not today. > Wading in late .. but is the gdbserver intended to run on an embedded RTOS with just threads? If so, then as a broad over generalization, it would be a shame to push any C++ run-time requirements on a target that is likely resource constrained. Plus some of the smaller gcc targets do not support C++. C++ for tools that will always run on a development host is a technical programming benefits decision. But please remember that host does not universally equal target. What may be right for one side may not be for the other. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 16:31 ` Joel Sherrill @ 2012-04-18 16:50 ` Pedro Alves 2012-04-18 16:57 ` Joel Brobecker 0 siblings, 1 reply; 116+ messages in thread From: Pedro Alves @ 2012-04-18 16:50 UTC (permalink / raw) To: Joel Sherrill Cc: Joel Brobecker, Jan Kratochvil, Pedro Alves, Tom Tromey, gdb On 04/18/2012 05:31 PM, Joel Sherrill wrote: > On 04/18/2012 11:22 AM, Joel Brobecker wrote: >>> What can change? C++ usage is already decreasing, most of the new >>> development is in Java. If C++ is already not suitable it will never >>> be. >> Many things can change. Just one example: The constraints placed >> on GDB/GDBserver could change and lead to a more positive terrain >> for C++ adoption. Maybe, one day, the conditions will be right. >> Just not today. >> > Wading in late .. but is the gdbserver intended to run > on an embedded RTOS with just threads? No, it assumes some more unixy-ish OS what spawns processes, though it scales down to Linux with uclibc, bionic, and other userspaces (along with supporting a few other OSs, like Lynx, Windows and Windows CE.) It could be made to bolt into such embedded targets, but nobody has ever done that, AFAIK. > > If so, then as a broad over generalization, it would be a > shame to push any C++ run-time requirements on a > target that is likely resource constrained. Plus some of > the smaller gcc targets do not support C++. > > C++ for tools that will always run on a development host > is a technical programming benefits decision. > > But please remember that host does not universally > equal target. What may be right for one side may not > be for the other. > -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 16:50 ` Pedro Alves @ 2012-04-18 16:57 ` Joel Brobecker 2012-04-18 17:28 ` Joel Sherrill 2012-04-18 17:40 ` Paul_Koning 0 siblings, 2 replies; 116+ messages in thread From: Joel Brobecker @ 2012-04-18 16:57 UTC (permalink / raw) To: Pedro Alves; +Cc: Joel Sherrill, Jan Kratochvil, Tom Tromey, gdb > > Wading in late .. but is the gdbserver intended to run > > on an embedded RTOS with just threads? > > No, it assumes some more unixy-ish OS what spawns processes, > though it scales down to Linux with uclibc, bionic, and other > userspaces [...] The point remains valid, though, that GDBserver needs to remain reasonably small. We run LynxOS on boards that occasionally run out of memory, so resource management is a concern... -- Joel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 16:57 ` Joel Brobecker @ 2012-04-18 17:28 ` Joel Sherrill 2012-04-18 17:40 ` Paul_Koning 1 sibling, 0 replies; 116+ messages in thread From: Joel Sherrill @ 2012-04-18 17:28 UTC (permalink / raw) To: Joel Brobecker; +Cc: Pedro Alves, Jan Kratochvil, Tom Tromey, gdb On 04/18/2012 11:57 AM, Joel Brobecker wrote: >>> Wading in late .. but is the gdbserver intended to run >>> on an embedded RTOS with just threads? >> No, it assumes some more unixy-ish OS what spawns processes, >> though it scales down to Linux with uclibc, bionic, and other >> userspaces [...] > The point remains valid, though, that GDBserver needs to remain > reasonably small. We run LynxOS on boards that occasionally run > out of memory, so resource management is a concern... > Defining run-time requirements for gdb stubs, gdbserver, gdb itself and any other gdb components would be good as you discuss what changes might be considered for each. Introducing an undesirable dependency is easy. FWIW your LynxOS target board is likely what I could consider a large target for RTEMS. :) -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 ^ permalink raw reply [flat|nested] 116+ messages in thread
* RE: Will therefore GDB utilize C++ or not? 2012-04-18 16:57 ` Joel Brobecker 2012-04-18 17:28 ` Joel Sherrill @ 2012-04-18 17:40 ` Paul_Koning 2012-04-18 20:37 ` Frank Ch. Eigler 1 sibling, 1 reply; 116+ messages in thread From: Paul_Koning @ 2012-04-18 17:40 UTC (permalink / raw) To: brobecker, palves; +Cc: joel.sherrill, jan.kratochvil, tromey, gdb Same here. A NetBSD system with 128 MB of memory (there is more elsewhere, but not for that OS or for its processes). Gdbserver is a wonderful tool, making possible debugging that gdb could not possibly do because of its size. But for that to work it has to remain small. It's already pushing the limits (300k or so when linked statically). paul -----Original Message----- From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Joel Brobecker Sent: Wednesday, April 18, 2012 12:57 PM To: Pedro Alves Cc: Joel Sherrill; Jan Kratochvil; Tom Tromey; gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? > > Wading in late .. but is the gdbserver intended to run on an > > embedded RTOS with just threads? > > No, it assumes some more unixy-ish OS what spawns processes, though it > scales down to Linux with uclibc, bionic, and other userspaces [...] The point remains valid, though, that GDBserver needs to remain reasonably small. We run LynxOS on boards that occasionally run out of memory, so resource management is a concern... -- Joel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 17:40 ` Paul_Koning @ 2012-04-18 20:37 ` Frank Ch. Eigler 2012-04-18 20:38 ` Paul_Koning 0 siblings, 1 reply; 116+ messages in thread From: Frank Ch. Eigler @ 2012-04-18 20:37 UTC (permalink / raw) To: Paul_Koning; +Cc: brobecker, palves, joel.sherrill, jan.kratochvil, tromey, gdb <Paul_Koning@Dell.com> writes: > Same here. A NetBSD system with 128 MB of memory (there is more > elsewhere, but not for that OS or for its processes). Gdbserver is > a wonderful tool [...] It's already pushing the limits (300k or so when > linked statically). Has there been some experimentation performed to produce evidence that a C++ized gdbserver would be substantially larger? - FChE ^ permalink raw reply [flat|nested] 116+ messages in thread
* RE: Will therefore GDB utilize C++ or not? 2012-04-18 20:37 ` Frank Ch. Eigler @ 2012-04-18 20:38 ` Paul_Koning 0 siblings, 0 replies; 116+ messages in thread From: Paul_Koning @ 2012-04-18 20:38 UTC (permalink / raw) To: fche; +Cc: brobecker, palves, joel.sherrill, jan.kratochvil, tromey, gdb I don't know. Not by me, certainly. I just wanted to point out that space is a very real concern already. paul -----Original Message----- From: Frank Ch. Eigler [mailto:fche@redhat.com] Sent: Wednesday, April 18, 2012 4:37 PM To: Koning, Paul Cc: brobecker@adacore.com; palves@redhat.com; joel.sherrill@oarcorp.com; jan.kratochvil@redhat.com; tromey@redhat.com; gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? <Paul_Koning@Dell.com> writes: > Same here. A NetBSD system with 128 MB of memory (there is more > elsewhere, but not for that OS or for its processes). Gdbserver is a > wonderful tool [...] It's already pushing the limits (300k or so when > linked statically). Has there been some experimentation performed to produce evidence that a C++ized gdbserver would be substantially larger? - FChE ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 16:07 ` Joel Brobecker 2012-04-18 16:13 ` Jan Kratochvil @ 2012-04-18 20:36 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-04-18 20:36 UTC (permalink / raw) To: Joel Brobecker; +Cc: Jan Kratochvil, Pedro Alves, gdb >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: Joel> After reading the whole discussion, I think that there are not enough Joel> advantages outweighing the drawbacks for us to move to C++. Things Joel> may change in the future, but I also feel that there is too much Joel> resitance (within the group of GDB Maintainers) at this time, to make Joel> such a drastic change. I am a little bit surprised by that, since Joel> I thought only one or two of us had reservations, but clearly not so. Don't give up yet, maybe I will convince Pedro :-) But if not, I think we will have to drop it and move on. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 15:54 ` Jan Kratochvil 2012-04-18 16:01 ` Pedro Alves 2012-04-18 16:07 ` Joel Brobecker @ 2012-04-18 17:48 ` John Gilmore 2012-04-18 19:07 ` Tom Tromey 2012-04-18 20:34 ` Will therefore GDB utilize C++ or not? Tom Tromey 3 siblings, 1 reply; 116+ messages in thread From: John Gilmore @ 2012-04-18 17:48 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, Tom Tromey, gdb > I do not repeat all the Bugs here leading to GDB crashes I get continuously > from ABRT (bugreporting system) in Bugzilla due to missing automatic code > sanity checking possible with C++. If you are arguing that our test suite does not exercise gdb well enough to detect simple coding bugs, that argues for spending more time on the test suite, not rewriting working code into C++. BTW, someone argued that C++ would improve memory allocation for e.g. symtabs. We used to allocate those in our own region-based memory allocator, so thousands of symbols could be freed at once when new symbol files are loaded. Do we not do that any more? John ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 17:48 ` John Gilmore @ 2012-04-18 19:07 ` Tom Tromey 2012-04-18 23:10 ` John Gilmore 0 siblings, 1 reply; 116+ messages in thread From: Tom Tromey @ 2012-04-18 19:07 UTC (permalink / raw) To: John Gilmore; +Cc: Jan Kratochvil, Pedro Alves, gdb >>>>> "John" == John Gilmore <gnu@toad.com> writes: I didn't reply to some of your earlier notes since they were just clearly bogus -- straw men, weird characterizations and generalizations bordering on the insulting, etc -- but a couple people asked me privately about these. So I guess I'll respond to this one after all. John> If you are arguing that our test suite does not exercise gdb well John> enough to detect simple coding bugs, that argues for spending more John> time on the test suite, not rewriting working code into C++. It doesn't really work this way. Test suites and reviews are good tools but of course they are imperfect. You can grind away to the point of diminishing returns, but the point is not perfection but rather to accelerate development at a reasonable cost, not an unreasonable one. The thrust of the argument that I posted, which you have basically ignored in all its particulars, is (1) gdb is already quite close to C++ in practice, albeit a badly broken dialect, and (2) the constructs gdb implements are in fact difficult to use correctly in practice. The evidence for #2 is all in the gdb-patches archives, mostly along the lines of bug fixes for various purely avoidable problems. In programming there are usually two sets of problems to solve. First, there are the domain problems. Then, there are the problems of expression; these are largely self-induced problems which tend to get worse as your program ages. My view is that gdb is hampered, though not crippled, by the latter class. John> BTW, someone argued that C++ would improve memory allocation for John> e.g. symtabs. We used to allocate those in our own region-based memory John> allocator, so thousands of symbols could be freed at once when new John> symbol files are loaded. Do we not do that any more? We do. Full symbols are already reasonably C++y, what with the ops vector. There are some threads on gdb-patches recently about lazy CU expansion where, reading between the lines (as one must usually do on gdb-patches, since bringing up C++ just makes for a distracting argument), you can see how C++ would help. Namely, we'd like to change symbol so that it can optionally point to the corresponding psymbol, but that means wackiness in the accessors; a problem easily and cleanly solved by subclassing and virtual methods. Note that we already have one subclass of symbols, and there's some indication we'll need more regardless. Anyway, this is a case where there would be a clarity benefit without any loss of space (in fact it would be in service of space and performance gains). Partial symbols are a different matter. I think they are a bad candidate for any sort of change, on the grounds that they are both reasonably isolated and also extremely space critical. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 19:07 ` Tom Tromey @ 2012-04-18 23:10 ` John Gilmore 2012-05-18 18:36 ` Tom Tromey 2012-05-18 18:51 ` Lazy CU expansion (Was: Will therefore GDB utilize C++ or not?) Tom Tromey 0 siblings, 2 replies; 116+ messages in thread From: John Gilmore @ 2012-04-18 23:10 UTC (permalink / raw) To: Tom Tromey; +Cc: John Gilmore, Jan Kratochvil, Pedro Alves, gdb > I didn't reply to some of your earlier notes since they were just > clearly bogus -- straw men, weird characterizations and generalizations > bordering on the insulting, etc -- but a couple people asked me > privately about these. So I guess I'll respond to this one after all. I had no desire to insult anyone, and I apologize if you were offended. I wish you'd retract the terms you used for my ideas (bogus, straw men, weird, etc). All of my messages on this topic have been serious. I do realize that I'm a decade out of doing regular daily programming on GDB, so I try to preface my characterizations with things like "If this is still true in the GDB design, then ...". > The thrust of the argument that I posted, which you have basically > ignored in all its particulars, is (1) gdb is already quite close to C++ > in practice, albeit a badly broken dialect, and (2) the constructs gdb > implements are in fact difficult to use correctly in practice. The > evidence for #2 is all in the gdb-patches archives, mostly along the > lines of bug fixes for various purely avoidable problems. Re (1), I could say that C is already quite close to C++, since GDB is written in C and you say GDB is already quite close to C++. But that is not an argument for converting C to C++ (or GDB to C++), it's just an observation. Large modular programs use modularity techniques. Some of those are also used by C++. Again, nice observation, but what does it have to do with converting GDB to C++? The crux of your argument is (2), that GDB is hard to maintain. And the key differences in our opinions on that are that: * Just because it's written in C++ doesn't make it maintainable. My experience so far is that large C programs tend to be more maintainable than large C++ programs. You may dismiss this as an insulting generalization, but again, I can't comment on the actual maintainability of the actual C++ version of GDB, because it doesn't exist. All I have is experience to guide me. And below is my experience with the maintainability of the C GDB. * I introduced the first ops-vector into GDB (and co-designed and built BFD, which made the second ops-vector). But I was receiving many patches on bug-gdb long before we had any ops-vectors and long before we had any exceptions, and it was the rare patch that actually worked. My own early patches to GDB produced a variety of bugs, before I understood it. And touching anything in wait_for_inferior was guar-an-teeeeeed to produce obscure bugs. See, GDB was a large, complex program even in 1991. And the average guy who makes a patch to a large program, makes it solve his particular problem but usually breaks six other things in the process. Those patches that people submitted were great guides to intuiting "what the user's actual problem is", which was often unclear from the bug report. But the GDB maintainer (in that case me) had to apply their knowledge of the structure of GDB in order to *fix* the problem in a correct way, once they understood what the problem is. Most such posted patches I would just read, debug the real problem, and patch it my own way. With a few people who seemed to have more insight, I would point out the problems in their patch and ask them to revise it to solve those problems. Or I'd point out that e.g. they'd patched the code but not the documentation, and would they please also do that. By training them up that way, ultimately many of those people (like Fred Fish) became valuable GDB contributors and even were hired as valuable Cygnus employees. But you can't afford to do that for more than about 10% of the patches. The guy who wrote the patch has solved his own problem and usually doesn't care to rewrite his patch, doesn't have the insight to fix it up, or doesn't have the programming chops to do it well. And it takes more work to train somebody, than to just do the work yourself, so you have to ration your own time. You just have to resolutely NOT APPLY the other 90% of the patches, using them only as an informal guide to where problems might be lurking. So if there are tons of contributed patches in gdb-patches, for "purely avoidable problems" that are in the shipping version of GDB, then they probably result from prior acts of the GDB maintainers, who inappropriately applied patches from people who don't understand the structure of GDB. I would strongly doubt the integrity of these tons of subsequent contributed patches too, unless they came from a small set of people who have already made a bunch of GDB patches; they are again more likely to tear up the guts of GDB and create four other problems, than they are to fix an existing problem. Again I'm speaking in generalities, but these generalities are grounded in years of being the GDB maintainer and reading all the patches posted to bug-gdb and gdb-patches. In summary, I don't think the fact that the average guy can't patch GDB is an artifact of its being written in C. I think it's an artifact of it being a large, complex program. I don't think a rewrite, into any language, is going to fix that. > There are some threads on gdb-patches recently about lazy CU expansion Also, I'm not sure what "lazy CU expansion" is. I did find a bug (PR 12708 at http://sourceware.org/bugzilla/show_bug.cgi?id=12708) that mentions "CU expansion" but it never says what that means. Clearly it's something to do with tab-expansion of mangled C++ types. It seems to have been a psymtab bug, since --readnow fixed it. Aha! The test case for that bug mentions "Compilation Unit" expansion. Of course, must be obvious (to somebody -- though web search engines did not turn up any useful references). This, it seems to me, means turning a psymtab into a symtab. Is that what we're talking about? > Namely, we'd like to change symbol so that it > can optionally point to the corresponding psymbol, but that means > wackiness in the accessors; a problem easily and cleanly solved by > subclassing and virtual methods. Note that we already have one subclass > of symbols, and there's some indication we'll need more regardless. By psymbol I presume you mean partial_symbol. And I'm working from your email message (in which you read between the lines of some gdb-patches); I haven't looked at those patches since you weren't specific about which ones you're talking about. The whole design of partial_symbols was that they're only needed when the real symbols haven't been read in. This is well documented. In fact the partial_symtab for a file can be (or used to be able to be) thrown away when the real symtab is created, and many symbol-readers never bothered to create partial_symbols. Partial symtabs were only a speed optimization to avoid parsing Stabs debugging info when host machines ran at 20 megahertz. You could probably get rid of them entirely nowadays. Now, you could conceivably keep the partial_symtab (and hope that it pages out since you'll never access it), and at some later point, throw away the entire real symtab. Then subsequent accesses to this range of addresses or symbols would again start accessing the partial_symtab. This would let you reclaim some memory, but would require a reread of these symbols the next time execution stopped inside this file (or someone accessed a partial_symbol from it). (You'd also have to do a sweep of all other symbol pointers, e.g. for saved $37 values, to make sure that none of them point into the symtab you're trying to throw away.) But I think the idea in these patches is some idea that's much more granular than that, like throwing away 95% of the symbols in a file, while retaining 5%? Or only reading in 5%, and then going back to reread other symbols into the same symtab later? Is it really faster and cheaper to throw away and reread symbols, than it is to let the operating system's virtual memory page them in and out? The beauty of virtual memory is that it does cacheing without requiring any programming changes. (Yes, you can optimize virtual memory based programs by avoiding accesses that would run all over the memory space. That was part of the idea of keeping the symbols in obstacks, where they're all close to each other in memory. If you want to throw 95% of them away, what kind of memory allocator do you plan to use to preserve the locality of reference of the remaining 5%?) The GDB Internals manual (which I originated when I discovered that there was no internals documentation) makes it clear that there are only a few ways to look up a symbol. Has that nice clean bit of modular C programming has been retained over the last decade? If so, then you could change the implementation of symbol tables in just those few places, so that the lookup code would handle symbols that pointed to partial_symbols. And as long as the full symbol got created before those few lookup functions returned and some other bit of code went poking around in the guts of the symbol, then the rest of GDB wouldn't need to change. (That modularity is how psymtabs work, too; most of GDB never needs to care about them, and none of it needs to depend upon their existence.) But if you're going to have a struct symbol that other things can point to, but which internally only contains a psymbol pointer, you'll still need to allocate all the space for the whole struct symbol. Because when someone touches it and you need to read the real symbol in, you can't change the address of the struct symbol. (If you did change its address, then you'd have to find all the things that point to it, and revise those pointers to point to the new one.) So how is this idea of pointing to psymbols going to save any memory? And if you're going to have to allocate all the memory for the struct symbol, then why not populate it with the real information for the symbol, instead of just a psymbol pointer? Or else are you talking about only reading in a few symbols from a symbol-file when a lookup indicates that you need to expand a psymtab into a symtab? You could try that, but it's probably a hive of bugs, because you'd have to recurse to find all the symbols that the symbol-of-interest needs. It's much simpler to read all the symbols in a symbol file, in order, and once you're doing that anyway, you might as well save them all. (You could try doing a super cheap optimization and merely stop reading and creating symbols after you've defined the particular symbol that you are looking for. This wouldn't require symbols-that-point-to-psymbols; it would instead require lookups to look in both the psymtab and the symtab, even if there's a symtab. This would also involve removing duplicates, now that we'd look at both, or require some fancy footwork to only look in the PART of the psymtab that hadn't already been read into a symtab. Subsequent efforts to expand the psymtab to find some different symbol, would resume reading from where the previous symbol-reading-and-creation left off. This would probably be a much easier change than to make a symtab entry be able to point to a psymtab entry.) > Full symbols are already reasonably C++y, what with the ops vector. It looks to me like the "ops vector" in symbols in gdb-7.4 is pretty minimal, only applying to a tiny number of symbol categories (and the comments in findvar.c -- from 2004 -- report that DWARF2 symbols screw up the ops vector anyway). Large parts of GDB touch symbols; is the idea that all of these will be rewritten to indirect through an ops-table (either explicitly in C, or implicitly in C++) without ever accessing fields (like SYMBOL_CLASS(sym)) directly? Do you think this will make GDB faster and smaller? I don't. (There's a comment in symtab.c from 2003 that says address classes and ops vectors should be merged. But clearly nobody has felt like doing that work in the last 9 years -- probably because so many places in the code would need to be touched. You can't use C++ to overload those symbols without touching all the same places that nobody wanted to touch for a decade.) In conclusion, why does making this change require (or encourage) C++? The idea seems to require changing a ton of working code, whether it's ultimately done in C or in C++, which makes it an unappetizing change in any language. It would take a powerful heap of benefit to make it worth doing that. John ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 23:10 ` John Gilmore @ 2012-05-18 18:36 ` Tom Tromey 2012-05-18 18:47 ` Paul_Koning 2012-05-18 18:51 ` Lazy CU expansion (Was: Will therefore GDB utilize C++ or not?) Tom Tromey 1 sibling, 1 reply; 116+ messages in thread From: Tom Tromey @ 2012-05-18 18:36 UTC (permalink / raw) To: John Gilmore; +Cc: Jan Kratochvil, Pedro Alves, gdb I'm sorry this reply has taken so long. I didn't mean to let this drop off -- I think a sort of generic problem in gdb is over-use of the pocket veto -- but I've been away, sick, etc. John> I wish you'd retract the terms you used for my ideas (bogus, straw John> men, weird, etc). Ok, I retract those adjectives. John> All of my messages on this topic have been serious. Ok. John> Re (1), I could say that C is already quite close to C++, since GDB John> is written in C and you say GDB is already quite close to C++. Your statement here is a generic one, disconnected from any particular fact about GDB -- a problem that pervades your response. It could apply to any C program. But, my argument is about GDB in particular; and cannot be transferred to any C program as-is. You can see this most easily if you re-read the bullet list in http://sourceware.org/ml/gdb/2012-04/msg00044.html John> Large modular programs use modularity techniques. Some of those John> are also used by C++. Again, nice observation, but what does it John> have to do with converting GDB to C++? The list isn't only about modularity techniques. For instance, few pure C programs use exceptions -- it is a rarity. But, GDB uses them ubiquitously, and we know that their current expression in GDB causes bugs; bugs which are easily avoided in C++. John> * Just because it's written in C++ doesn't make it John> maintainable. Nobody claims this. John> See, GDB was a large, complex program even in 1991. And the average John> guy who makes a patch to a large program, makes it solve his John> particular problem but usually breaks six other things in the process. There are lots of kinds of patches. And, there is no silver bullet. I don't think C++ will magically solve everything, but it will remove some subset of bugs and make some planned changes easier. And, this proposal can't really be disconnected from gdb as it currently is. For example, look at the Python layer. Despite patch review and our knowledge of the issues, we still have error-checking and reference-counting bugs in the code. You can go through the list archives and find them. This is an example of the sort of problem that we could define out of existence. Cleanups are another good example. I've personally fixed any number of small memory leaks, cleanup misuses, etc -- but more remain. RAII is simply a better programming technique. The frame cache is yet another example. There's a bunch of bugs relating to keeping frame_info objects across invalidations of the frame cache. These are very tricky to see via patch review. This is also a hard problem to fix systematically in C. In C++ you can do it pretty easily though. John> So if there are tons of contributed patches in gdb-patches, for John> "purely avoidable problems" that are in the shipping version of GDB, John> then they probably result from prior acts of the GDB maintainers, who John> inappropriately applied patches from people who don't understand the John> structure of GDB. Patch review will never be perfect. It is typical for even very experienced gdb hackers to miss things during review. My view is that we should use multiple tools to eliminate bugs at their source -- and that the cheapest way, by far, is to define them away by letting the compiler do the heavy work. Tom> There are some threads on gdb-patches recently about lazy CU expansion John> Also, I'm not sure what "lazy CU expansion" is. See http://sourceware.org/ml/gdb-patches/2012-04/msg00154.html Basically it is an attempt to scale gdb's symbol reading performance. Even this may not be sufficient, given the size of programs we're seeing now. I'll reply to the rest of this in a separate note. It is really a different thread. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 18:36 ` Tom Tromey @ 2012-05-18 18:47 ` Paul_Koning 2012-05-18 19:36 ` Tom Tromey 0 siblings, 1 reply; 116+ messages in thread From: Paul_Koning @ 2012-05-18 18:47 UTC (permalink / raw) To: tromey; +Cc: gdb On May 18, 2012, at 2:36 PM, Tom Tromey wrote: > ... > For example, look at the Python layer. Despite patch review and our > knowledge of the issues, we still have error-checking and > reference-counting bugs in the code. You can go through the list > archives and find them. How would C++ help with reference counting bugs? I could see how it might (or might not) help with the subset related to error handling that can be made clearer with exceptions. But the reference counting errors I remember were straight algorithmic mistakes that, as far as I can see, would have existed in the exact same form if the algorithm had been expressed in C++. paul ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 18:47 ` Paul_Koning @ 2012-05-18 19:36 ` Tom Tromey 2012-05-18 19:44 ` Paul_Koning 0 siblings, 1 reply; 116+ messages in thread From: Tom Tromey @ 2012-05-18 19:36 UTC (permalink / raw) To: Paul_Koning; +Cc: gdb >>>>> "Paul" == <Paul_Koning@Dell.com> writes: Tom> For example, look at the Python layer. Despite patch review and our Tom> knowledge of the issues, we still have error-checking and Tom> reference-counting bugs in the code. You can go through the list Tom> archives and find them. Paul> How would C++ help with reference counting bugs? I could see how it Paul> might (or might not) help with the subset related to error handling Paul> that can be made clearer with exceptions. But the reference counting Paul> errors I remember were straight algorithmic mistakes that, as far as I Paul> can see, would have existed in the exact same form if the algorithm Paul> had been expressed in C++. We'd use RAII to ensure that refcounts were automatically managed by the C++ compiler. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 19:36 ` Tom Tromey @ 2012-05-18 19:44 ` Paul_Koning 2012-05-18 20:07 ` Tom Tromey 0 siblings, 1 reply; 116+ messages in thread From: Paul_Koning @ 2012-05-18 19:44 UTC (permalink / raw) To: tromey; +Cc: gdb On May 18, 2012, at 3:20 PM, Tom Tromey wrote: >>>>>> "Paul" == <Paul_Koning@Dell.com> writes: > > Tom> For example, look at the Python layer. Despite patch review and our > Tom> knowledge of the issues, we still have error-checking and > Tom> reference-counting bugs in the code. You can go through the list > Tom> archives and find them. > > Paul> How would C++ help with reference counting bugs? I could see how it > Paul> might (or might not) help with the subset related to error handling > Paul> that can be made clearer with exceptions. But the reference counting > Paul> errors I remember were straight algorithmic mistakes that, as far as I > Paul> can see, would have existed in the exact same form if the algorithm > Paul> had been expressed in C++. > > We'd use RAII to ensure that refcounts were automatically managed by the > C++ compiler. That would be nice if the Python ABI is compatible with this. It may not be, or not always. For example, when some calls steal a reference while others (most of them) don't, and some return a borrowed reference while others return a new one, it isn't clear how a mechanical scheme like RAII will give you a full answer. Maybe if you use only the subset that does reference counting in the one way you want it done? There would be some performance impact but probably not much. paul ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 19:44 ` Paul_Koning @ 2012-05-18 20:07 ` Tom Tromey 2012-05-18 20:41 ` Aurelian Melinte 0 siblings, 1 reply; 116+ messages in thread From: Tom Tromey @ 2012-05-18 20:07 UTC (permalink / raw) To: Paul_Koning; +Cc: gdb >>>>> "Paul" == <Paul_Koning@Dell.com> writes: Tom> We'd use RAII to ensure that refcounts were automatically managed Tom> by the C++ compiler. Paul> That would be nice if the Python ABI is compatible with this. It may Paul> not be, or not always. For example, when some calls steal a reference Paul> while others (most of them) don't, and some return a borrowed Paul> reference while others return a new one, it isn't clear how a Paul> mechanical scheme like RAII will give you a full answer. I think you can write wrapper functions which abstract the details. We'd want this anyway so we can turn Python exceptions into C++ exceptions. boost::python basically does all this already, but I've been assuming we'd roll our own. Paul> Maybe if you use only the subset that does reference counting in Paul> the one way you want it done? There would be some performance Paul> impact but probably not much. I think the wrappers would be pretty thin, and there'd be no runtime hit to speak of. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 20:07 ` Tom Tromey @ 2012-05-18 20:41 ` Aurelian Melinte 0 siblings, 0 replies; 116+ messages in thread From: Aurelian Melinte @ 2012-05-18 20:41 UTC (permalink / raw) To: gdb On 18/05/2012 4:06 PM, Tom Tromey wrote: >>>>>> "Paul" ==<Paul_Koning@Dell.com> writes: >>>>>> > Tom> We'd use RAII to ensure that refcounts were automatically managed > Tom> by the C++ compiler. > C++11 (that is g++ 4.3 and later) offers an std::shared_pointer; non-intrusive (the reference is not in the object being pointed to). Regards, a. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Lazy CU expansion (Was: Will therefore GDB utilize C++ or not?) 2012-04-18 23:10 ` John Gilmore 2012-05-18 18:36 ` Tom Tromey @ 2012-05-18 18:51 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-05-18 18:51 UTC (permalink / raw) To: John Gilmore; +Cc: Jan Kratochvil, Pedro Alves, gdb >>>>> "John" == John Gilmore <gnu@toad.com> writes: Some comments on your comments about lazy CU expansion. John> The whole design of partial_symbols was that they're only needed when John> the real symbols haven't been read in. This is well documented. In John> fact the partial_symtab for a file can be (or used to be able to be) John> thrown away when the real symtab is created, and many symbol-readers John> never bothered to create partial_symbols. I don't think it's been possible to discard a partial symtab for many years now. It doesn't seem very worthwhile to do it, given that the bulk of the memory is in the psymbols themselves, and these can't ever be deleted. But, maybe it would be worth trying. John> Partial symtabs were only a John> speed optimization to avoid parsing Stabs debugging info when host John> machines ran at 20 megahertz. You could probably get rid of them John> entirely nowadays. This seems unlikely to me; but due to memory use, not CPU. Partial symbols take a lot less memory than full symbols, partly because they are smaller, but more importantly because they can be put into the bcache, and this is quite effective in practice. John> The GDB Internals manual (which I originated when I discovered that John> there was no internals documentation) makes it clear that there are John> only a few ways to look up a symbol. Has that nice clean bit of John> modular C programming has been retained over the last decade? No, the symbol tables are a total mess, and the internals manual is out of date. John> So how is this idea of pointing to psymbols going to save any John> memory? 'struct symbol' starts with a 'general_symbol_info', and also includes 'domain' and 'aclass' fields -- all of which are duplicated in the partial symbol. So, pointing to the partial symbol will save at least sizeof(general_symbol_info) - sizeof(void*) bytes per symbol. On x86-64 that is 32 bytes. Maybe it could save more memory with more packing. More importantly, this sort of thing would allow instantiation of a full symtab without re-parsing the DWARF. Re-parsing is slow, and also mostly pointless, as most symbols in a given CU are never used. John> And if you're going to have to allocate all the memory for the John> struct symbol, then why not populate it with the real information John> for the symbol, instead of just a psymbol pointer? Reading the remaining information is slow and uses memory, but the results are often not used. So it would be preferable to fill in the details on demand. Just skipping function bodies alone saves ~30% of the CU expansion time. John> It's much simpler to read all the symbols in a symbol file, in John> order, and once you're doing that anyway, you might as well save John> them all. Yes, it is simpler. This is what is done now. I think it doesn't scale very well... Jan has dug up some C++ libraries where there is one enormous CU which sucks up a lot of time if you happen to have to expand it. Tom> Full symbols are already reasonably C++y, what with the ops vector. John> It looks to me like the "ops vector" in symbols in gdb-7.4 is pretty John> minimal, only applying to a tiny number of symbol categories (and the John> comments in findvar.c -- from 2004 -- report that DWARF2 symbols screw John> up the ops vector anyway). Large parts of GDB touch symbols; is the John> idea that all of these will be rewritten to indirect through an John> ops-table (either explicitly in C, or implicitly in C++) without ever John> accessing fields (like SYMBOL_CLASS(sym)) directly? Do you think this John> will make GDB faster and smaller? I don't. I doubt it would be smaller. History indicates this is of zero importance. It would probably be faster. At least for lazy CU expansion, the changes are of the form: #define SYMBOL_TYPE(sym) \ ((sym)->type ? (sym)->type : compute_symbol_type (sym)) ... or moral equivalent. Rewriting is not necessary, you can redefine the macros. But, rewriting the uses would be better if we were moving to C++. This is easy though. John> (There's a comment in symtab.c from 2003 that says address classes and John> ops vectors should be merged. But clearly nobody has felt like doing John> that work in the last 9 years -- probably because so many places in the John> code would need to be touched. I'm not sure I trust that comment. I find that in general, comments in GDB relating to future maintenance issues are often questionable. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 15:54 ` Jan Kratochvil ` (2 preceding siblings ...) 2012-04-18 17:48 ` John Gilmore @ 2012-04-18 20:34 ` Tom Tromey 3 siblings, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-04-18 20:34 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, gdb >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: Jan> We can talk about the C gdbserver, I believe it can be forked from Jan> the current codebase and removed almost everything there, including Jan> threading support. But I do not have experience with new Jan> architectures bootstrapping myself. Someone could resurrect RDA :) http://sourceware.org/rda/ Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Will C++ proponents spend 20 minutes to try what they're proposing? 2012-04-18 15:16 ` Jan Kratochvil 2012-04-18 15:28 ` Pedro Alves @ 2012-04-18 19:18 ` John Gilmore 2012-04-18 19:23 ` Jan Kratochvil 2012-04-18 20:40 ` Tom Tromey 1 sibling, 2 replies; 116+ messages in thread From: John Gilmore @ 2012-04-18 19:18 UTC (permalink / raw) To: gdb, Jan Kratochvil, gnu [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 9184 bytes --] Jan Kratochvil said: > I can't believe we do not agree on such basic way forward. Changing the implementation language of a huge program, more than twenty years after its creation, is not "basic". Has any of the proponents even *tried* to compile and run today's GDB using a C++ compiler, to see what C constructs that it currently uses will be rejected by the C++ compiler? "./configure CC=g++; make check", or something similar, should do most of that for you. Recompiling the C code in C++ is the approach you're proposing to take, right? Or do you propose that we compile some source files with a C compiler and others with a C++ compiler? If it will compile easily with a C++ compiler, then you could start migrating small bits of it here and there to C++. If it won't compile easily, then there's a more substantial hurdle to cross before even a line of new C++ code could be written. Ideally if we were going to switch to C++, we'd migrate the current code base so that it would compile with either C or C++. Then and only then would we commit ourselves by writing new C++ code, knowing that we still have a working debugger. When I configure gdb-7.4 with C++ and make it, it fails pretty early here in libiberty: ./cplus-dem.c: In function âvoid demangle_arm_hp_template(work_stuff*, const char**, int, string*)â: ./cplus-dem.c:2351:46: error: invalid conversion from âconst char*â to âchar*â (I'm amused that the C++ demangler is the first C function to fail.) I've appended a bunch of other errors that turn up from "make -i". There are MANY more, and I didn't scan beyond the "f"s in BFD. (The GDB source files themselves also get a ton of errors). Yes, I realize many of these are simple fixes. Perhaps a proponent should make these fixes. Some of them bother me, e.g. "deprecated string constant conversion to char *". C code regularly uses strings with char *'s. Is this a foolish hobgoblin of const-correctness? PS: When did g++ start outputting non-ascii (Unicode) backquotes and forward-quotes in its error messages? That's truly ugly. Look at the compiler output in Emacs, for example. John ./md5.c: In function âvoid* md5_finish_ctx(md5_ctx*, void*)â: ./md5.c:117:43: warning: dereferencing type-punned pointer will break strict-aliasing rules ./md5.c:118:47: warning: dereferencing type-punned pointer will break strict-aliasing rules ./alloca.c: In function âvoid* C_alloca(size_t)â: ./alloca.c:164:3: warning: âautoâ will change meaning in C++0x; please remove it ./floatformat.c:22:0: warning: "_GNU_SOURCE" redefined <command-line>:0:0: note: this is the location of the previous definition ./stack-limit.c:52:27: warning: use of C++0x long long integer constant ./stack-limit.c:54:28: warning: use of C++0x long long integer constant ./stack-limit.c:57:28: warning: use of C++0x long long integer constant In file included from archive.c:131:0: bfd.h:6246:31: error: âbfd_boolean bfd_section_already_linked(bfd*, asection*, bfd_link_info*)â hides constructor for âstruct bfd_section_already_linkedâ In file included from archive.c:132:0: ./../include/libiberty.h:110:36: error: new declaration âchar* basename(const char*)â /usr/include/string.h:603:28: error: ambiguates old declaration âconst char* basename(const char*)â archive.c: In function âbfd_boolean _bfd_write_archive_contents(bfd*)â: archive.c:2115:11: error: deprecated conversion from string constant to âchar*â archive.c:2117:13: error: deprecated conversion from string constant to âchar*â In file included from bfd.c:319:0: cache.c: In function âvoid* cache_bmmap(bfd*, void*, bfd_size_type, int, int, file_ptr, void**, bfd_size_type*)â: cache.c:440:27: error: pointer of type âvoid *â used in arithmetic srec.c:1324:1: error: deprecated conversion from string constant to âchar*â srec.c:1380:1: error: deprecated conversion from string constant to âchar*â binary.c: In function âchar* mangle_name(bfd*, char*)â: binary.c:135:12: error: deprecated conversion from string constant to âchar*â binary.c: In function âlong int binary_canonicalize_symtab(bfd*, asymbol**)â: binary.c:163:44: error: deprecated conversion from string constant to âchar*â binary.c:171:42: error: deprecated conversion from string constant to âchar*â binary.c:179:43: error: deprecated conversion from string constant to âchar*â binary.c: At global scope: binary.c:369:1: error: deprecated conversion from string constant to âchar*â tekhex.c:1016:1: error: deprecated conversion from string constant to âchar*â ./dwarf2.c: In function âint compare_sequences(const void*, const void*)â: ./dwarf2.c:1299:38: error: invalid conversion from âconst void*â to âconst line_sequence*â ./dwarf2.c:1300:38: error: invalid conversion from âconst void*â to âconst line_sequence*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c:185:1: error: deprecated conversion from string constant to âchar*â elf32-i386.c: In function âbfd_boolean elf_i386_grok_prstatus(bfd*, Elf_Internal_Note*)â: elf32-i386.c:454:36: error: deprecated conversion from string constant to âchar*â elf32-i386.c: In function âbfd_boolean elf_i386_create_dynamic_sections(bfd*, bfd_link_info*)â: elf32-i386.c:1030:47: error: invalid conversion from âvoid*â to âunsigned char*â In file included from elf32-i386.c:4989:0: elf32-target.h: At global scope: elf32-target.h:987:1: error: deprecated conversion from string constant to âchar*â In file included from elf32-i386.c:5022:0: elf32-target.h:987:1: error: deprecated conversion from string constant to âchar*â In file included from elf32-i386.c:5050:0: elf32-target.h:987:1: error: deprecated conversion from string constant to âchar*â In file included from elf32-i386.c:5214:0: elf32-target.h:987:1: error: deprecated conversion from string constant to âchar*â In file included from elf32-i386.c:5259:0: elf32-target.h:987:1: error: deprecated conversion from string constant to âchar*â ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will C++ proponents spend 20 minutes to try what they're proposing? 2012-04-18 19:18 ` Will C++ proponents spend 20 minutes to try what they're proposing? John Gilmore @ 2012-04-18 19:23 ` Jan Kratochvil 2012-04-18 20:40 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-04-18 19:23 UTC (permalink / raw) To: John Gilmore; +Cc: gdb On Wed, 18 Apr 2012 21:18:21 +0200, John Gilmore wrote: > Has any of the proponents even *tried* to compile and run today's GDB > using a C++ compiler, Yes (OK, not myself), using: http://sourceware.org/gdb/wiki/ArcherBranchManagement archer-ratmice-compile-Wc++-compat Ratmice has even preliminarily confirmed he would update the branch for HEAD if the C++ move happens. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will C++ proponents spend 20 minutes to try what they're proposing? 2012-04-18 19:18 ` Will C++ proponents spend 20 minutes to try what they're proposing? John Gilmore 2012-04-18 19:23 ` Jan Kratochvil @ 2012-04-18 20:40 ` Tom Tromey 2012-04-18 20:56 ` Mike Frysinger 1 sibling, 1 reply; 116+ messages in thread From: Tom Tromey @ 2012-04-18 20:40 UTC (permalink / raw) To: John Gilmore; +Cc: gdb, Jan Kratochvil >>>>> "John" == John Gilmore <gnu@toad.com> writes: John> Has any of the proponents even *tried* to compile and run today's GDB John> using a C++ compiler, to see what C constructs that it currently uses John> will be rejected by the C++ compiler? Yeah. Also with -Wc++-compat. John> Recompiling the C code in C++ is the approach you're proposing to John> take, right? Or do you propose that we compile some source files with John> a C compiler and others with a C++ compiler? No, please see the plan that I posted upthread. It lays out exactly what we propose. http://sourceware.org/ml/gdb/2012-04/msg00044.html Search for "concrete transition proposal". John> When I configure gdb-7.4 with C++ and make it, it fails pretty early John> here in libiberty: We'd only convert gdb, not libiberty, bfd, etc. John> PS: When did g++ start outputting non-ascii (Unicode) backquotes John> and forward-quotes in its error messages? That's truly ugly. Look John> at the compiler output in Emacs, for example. There's some long threads about this all over GNUdom. I can't remember when, it seems like a long time ago now. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will C++ proponents spend 20 minutes to try what they're proposing? 2012-04-18 20:40 ` Tom Tromey @ 2012-04-18 20:56 ` Mike Frysinger 0 siblings, 0 replies; 116+ messages in thread From: Mike Frysinger @ 2012-04-18 20:56 UTC (permalink / raw) To: gdb; +Cc: Tom Tromey, John Gilmore, Jan Kratochvil [-- Attachment #1: Type: Text/Plain, Size: 1152 bytes --] On Wednesday 18 April 2012 16:39:53 Tom Tromey wrote: > >>>>> "John" == John Gilmore <gnu@toad.com> writes: > John> PS: When did g++ start outputting non-ascii (Unicode) backquotes > John> and forward-quotes in its error messages? That's truly ugly. Look > John> at the compiler output in Emacs, for example. > > There's some long threads about this all over GNUdom. > I can't remember when, it seems like a long time ago now. at least they've started moving away from the left quote being a backtick. but yes, i believe GNU projects have been doing unicode quotes for a while. recent gnulib commit: commit 1a43a982c927eaf26bbc2701a872009d9be4b33b Author: Paolo Bonzini <bonzini@gnu.org> Date: Sun Dec 18 15:44:17 2011 +0100 quotearg: do not use grave accent for left quote * lib/quotearg.c (gettext_quote): Map "`" to "'" for locale_quoting_style. (quotearg_buffer_restyled): Fix example. * tests/test-quotearg-simple.c (results_g): Adjust test vectors. and indeed, grep-2.11 says: Try 'grep --help' for more information. where it once said: Try `grep --help' for more information. -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-16 6:55 ` Jan Kratochvil 2012-04-18 14:11 ` Pedro Alves @ 2012-04-18 20:31 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-04-18 20:31 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, gdb >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: Jan> If GDB should stay with C then OK (although FYI I am not so in Jan> favor of it). But then it should be real C - therefore without GDB Jan> cleanups, without GDB TRY_CATCH etc. etc., proper C code returning Jan> error codes from each function and each caller checking it and Jan> doing all the local cleanups by hand. I can't tell if you're joking here, but I don't think it would be very practical to do this. It would be an enormous effort. I have wondered whether we could limit gdbserver and the shared code in this way. But I assume that is impractical as well; and now I am more interested in measuring the actual impact of C++, rather than assuming it is very bad. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 19:49 ` Pedro Alves ` (2 preceding siblings ...) 2012-04-16 6:55 ` Jan Kratochvil @ 2012-04-18 20:25 ` Tom Tromey 2012-05-21 18:11 ` Pedro Alves 3 siblings, 1 reply; 116+ messages in thread From: Tom Tromey @ 2012-04-18 20:25 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb >>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes: Pedro> Even Android/Bionic doesn't support C++ exceptions (not sure Pedro> if it doesn't in recent versions or not). I think this is an interesting point, but downthread Paul Smith raised the idea of statically linking libstdc++; and I was wondering whether on really space-constrained systems one might enable SJLJ exceptions to try to save space from the unwind tables, my thinking being that this would reasonably faithfully mimic how the code actually works today. Pedro> It is very much not clear to me that it is worth the pain (that I Pedro> tried to show we will end up with) to bring in C++ for this. Pedro> Symbol/types even are long lived objects, it's not common at all Pedro> to need to worry about leaks (RAII/exceptions) here. And all we Pedro> have are simple hierarchies. As much as I like C++, C does quite Pedro> fine here too. The language it is written in is not the problem Pedro> with our symbol tables. We're going to make symbols more complicated to make lazy CU expansion work, and maybe some other things. The issue isn't whether it is possible, but instead the cost. On the whole I think we spend a lot of time in gdb tending to self-created problems. Open data structures (symbol tables are particularly bad here), inconsistent use of accessors, etc, make some kinds of refactorings harder than they need to be. I realize that switching to C++ is not a panacea for this. Fixing symbol tables is just hard regardless of how we do it, because the original sins are all baked into the code already. But, there are changes that this move would undoubtedly facilitate. For example, I think we need to virtualize struct value storage to deal with VLA and sliced arrays. To me this looks pretty awful from C; but simpler from C++. Pedro> Even RAII is not _that_ different from cleanups. No, it really is. It is not dynamic, and you don't have to remember to call do_cleanups on all exit paths. I've fixed any number of memory (and, IIRC, file descriptor) leaks caused precisely because cleanups are less good than RAII. Basically, with cleanups the default is full generality, but this is wrong. With RAII the default is block scoping, and you have to expend effort to do weird stuff. Pedro> We still need to have a way to tell the RAII wrapper objects to Pedro> stop managing whatever they're managing, for instance. There are plenty of canned solutions. Pedro> We should consider this very very carefully, not just flip just Pedro> because. I don't think that is an accurate characterization of the proposal. I realize the threads get a bit heated though. I agree that we should consider it very carefully. And I think we are. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 20:25 ` Tom Tromey @ 2012-05-21 18:11 ` Pedro Alves 2012-05-21 18:36 ` Jan Kratochvil 2012-11-21 20:18 ` Jan Kratochvil 0 siblings, 2 replies; 116+ messages in thread From: Pedro Alves @ 2012-05-21 18:11 UTC (permalink / raw) To: Tom Tromey; +Cc: Jan Kratochvil, gdb On 04/18/2012 09:24 PM, Tom Tromey wrote: > Pedro> Even RAII is not _that_ different from cleanups. > > No, it really is. It is not dynamic, and you don't have to remember to > call do_cleanups on all exit paths. Cleanups are dynamic because they're been crafted that way. We could tweak cleanups to allow creating them on the stack. What I meant by not that different, is, that with RAII you get to write something like (the dumbest version of a RAII object that supports canceling possible): class my_raii_thing { private: whatever_arg *arg; << moral equivalent of the cleanup args. bool discarded; public: my_raii_thing (whatever_arg *p) : arg (p), discarded(false) {} ~my_raii_thing () << moral equivalent of a cleanup function. { if (!discarded) { // whatever to release this->arg or something like that. } } void discard () { discarded = true; } }; and then do: my_raii_thing foo (&whatever_arg); if (whatnot) { whatever_arg.discard(); return SUCESS; } } whereas we now write: struct cleanup_args { ... }; void foo_cleanup (void *arg) { // whatever to release this->arg or something like that. } and then: old_chain = make_cleanup (foo_cleanup, &whatever_arg); if (whatnot) { discard_cleanups (old_chain); return SUCESS; } do_cleanup (old_chain); But yes, as I've said before elsewhere, give me destructors, everything else I can live without. :-) Basically, whoever understands RAII should understand cleanups. Not counting the auto-destruction issue, I'm saying that writing raii classes vs writing cleanup function is mostly syntax sugar. > > I've fixed any number of memory (and, IIRC, file descriptor) leaks > caused precisely because cleanups are less good than RAII. > > Basically, with cleanups the default is full generality, but this is > wrong. With RAII the default is block scoping, and you have to expend > effort to do weird stuff. We could make make_cleanup return a reference to this instead of to the previous (as Doug suggested not long ago), and tweak cleanups to make it possible to have them on the stack, making their use follow scope closer too. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 18:11 ` Pedro Alves @ 2012-05-21 18:36 ` Jan Kratochvil 2012-11-21 20:18 ` Jan Kratochvil 1 sibling, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-05-21 18:36 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Mon, 21 May 2012 18:27:48 +0200, Pedro Alves wrote: > and then: > > old_chain = make_cleanup (foo_cleanup, &whatever_arg); > > if (whatnot) > { > discard_cleanups (old_chain); > return SUCESS; > } > do_cleanup (old_chain); > > But yes, as I've said before elsewhere, give me destructors, > everything else I can live without. :-) > > Basically, whoever understands RAII should understand cleanups. > Not counting the auto-destruction issue, I'm saying that writing > raii classes vs writing cleanup function is mostly syntax sugar. With RAII you do not have to write many times in that function that do_cleanup statement (for multiple cleanup markers), which makes one of the differences. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 18:11 ` Pedro Alves 2012-05-21 18:36 ` Jan Kratochvil @ 2012-11-21 20:18 ` Jan Kratochvil 1 sibling, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-11-21 20:18 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Mon, 21 May 2012 18:27:48 +0200, Pedro Alves wrote: > What I meant by not that different, is, that with RAII you get > to write something like (the dumbest version of a RAII object > that supports canceling possible): > > class my_raii_thing > { > private: > whatever_arg *arg; << moral equivalent of the cleanup args. > bool discarded; > > public: > my_raii_thing (whatever_arg *p) : arg (p), discarded(false) > {} > > ~my_raii_thing () << moral equivalent of a cleanup function. > { > if (!discarded) > { > // whatever to release this->arg or something like that. > } > } > > void discard () > { > discarded = true; > } > }; > > and then do: > > my_raii_thing foo (&whatever_arg); > > if (whatnot) > { > whatever_arg.discard(); > return SUCESS; > } > } I find it too complicated, why not just shared_ptr: #include <memory> #include <iostream> using namespace std; class R { public: R() { cout << "R new" << endl; } ~R() { cout << "R delete" << endl; } string val() { return "isR"; } }; static shared_ptr<R> getR(bool fail) { auto v=shared_ptr<R>(new R()); if (fail) throw fail; return v; } int main() { try { getR(true); } catch (...) {} cout << getR(false)->val() << endl; } R new R delete R new isR R delete As C++11 dependency is probably too strict one can use Boost instead and as GDB does not like external dependencies stripped down Boost can be bundled to the sourceware repository - on normal systems sure C++11 libraries get used instead. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 18:41 ` Pedro Alves 2012-04-09 19:05 ` Jan Kratochvil @ 2012-04-10 0:23 ` Yao Qi 2012-04-10 9:47 ` Yao Qi 2012-04-18 20:11 ` Tom Tromey ` (2 subsequent siblings) 4 siblings, 1 reply; 116+ messages in thread From: Yao Qi @ 2012-04-10 0:23 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, Jan Kratochvil, gdb On 04/10/2012 02:41 AM, Pedro Alves wrote: > Indeed, gdbserver would need to remain pure C, and likewise any > code shared between gdbserver and gdb should have to be kept > as such. This is important, because we want gdbserver to be usable > in #1, resource constrained scenarios where the C++ dependency would > be unacceptable. We don't want there to need to be other gdbserver-like > programs specialized for such environments, and gdbserver to be usable only > on bigger machines. We want gdbserver to run everywhere. And #2, the debugger I agree. The system configure or capability of embedded devices are diversiform, from tiny piece of memory to multiple giga-bytes of memory. GDBserver fits to low-end devices. Even nowadays, the size of GDBserver increases as more functionalities added, we should avoid GDBserver depends on C++ libraries. > is one of the first programs that is desirable to get running on a new > system/board. Usually you get C going much sooner than C++. > Yes, when building up a system on a board, GDBserver is usually the "first class" programs to build. > > I'm very wary that introducing C++ will make it increasingly > difficult to share between the C++ and C parts. Currently not > that much is shared between gdb and gdbserver, but it is long desired, > and in actually in this year's plan to merge gdb's and gdbserver's > backends (am I am actively working on this. See > <http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity>). Agree. We have multiple codes to share among GDB and GDBserver, this will reduce the scope of GDB C++-fication. > There's also the issue with in-process code, which is also > desirable to remain as C code. Latest developments push towards having > debugger code run _within_ the inferior. Witness gdbserver's current IPA > (in-process agent; libinproctrace.so), which has a lot of coupling in its > implementation (and a lot of code shared), and a bunch of code shared with > gdbserver. We can't predict which bits of GDB will we want to be able to > reuse in GDBserver or an IPA, but I do believe that we will be considering > it (reuse something more) the future. > As GDBserver and in-process agent becomes more and more powerful (which is the trend of debugging, IMO), they will share more and more code with GDB. For example, when supporting ITSET in GDBserver and in-proc agent, even the design is not mature, it shows that we need move some bits of GDB to gdb/common, and share with GDBserver and in-proc agent. > So all in all, I believe that in a C++ world, GDB's "C++ in C" wouldn't > really go away; it would end up still being prominent, not as hidden as > libbfd or other dependencies. Not hidden enough that we could just > tuck it under the carpet. I worry that this actually makes it _worse_ > for new contributers, who will need to learn about GDB's C idiomatic usage, > and whatever new C++ idiomatic usage GDB would end up with. With that, and > the worry about the new source of trouble and bugs and confusion that > it would be the bridging between the parts written in the different languages, > I do believe we're better off staying in C land, at least for a couple years more. In short, I am not against using C++ in GDB. -- Yao (é½å°§) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-10 0:23 ` Yao Qi @ 2012-04-10 9:47 ` Yao Qi 0 siblings, 0 replies; 116+ messages in thread From: Yao Qi @ 2012-04-10 9:47 UTC (permalink / raw) To: gdb On 04/10/2012 08:22 AM, Yao Qi wrote: > In short, I am not against using C++ in GDB. Looks like this sentence is conflict with my words above. :) I am NOT against using C++ in GDB, but we should carefully identify the areas to C++-fy, because they may/will be shared with GDBserver, which is not C++-fied. -- Yao (é½å°§) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 18:41 ` Pedro Alves 2012-04-09 19:05 ` Jan Kratochvil 2012-04-10 0:23 ` Yao Qi @ 2012-04-18 20:11 ` Tom Tromey 2012-04-18 20:31 ` Can it really be ok to map GPL'd code into any old process? John Gilmore 2012-04-23 18:03 ` Will therefore GDB utilize C++ or not? Tom Tromey 2012-05-18 19:55 ` Tom Tromey 2012-11-22 18:46 ` Jan Kratochvil 4 siblings, 2 replies; 116+ messages in thread From: Tom Tromey @ 2012-04-18 20:11 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb >>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes: Pedro> If you asked me not too long ago, I'd have been strongly in favor Pedro> of C++. However, that is no longer the case. I'm now pending Pedro> towards "no C++". First, let me say, thanks for your considered opinion. I'm sorry it has taken me so long to reply, but various personal events have made it hard to do so in a more timely way. Luckily (?) the thread rages on, so I don't feel too awfully tardy. Pedro> Indeed, gdbserver would need to remain pure C, and likewise any Pedro> code shared between gdbserver and gdb should have to be kept Pedro> as such. This is important, because we want gdbserver to be usable Pedro> in #1, resource constrained scenarios where the C++ dependency would Pedro> be unacceptable. I found this post to be sensible and I basically agreed with everything you said -- I'm sort of dog-like and easily swayed by the last thing I saw -- but on reflection I think the above paragraph is the crux of the argument, and I am not sure I agree with it. I think this relies on the idea that the C++ runtime dependency is unavoidably very heavy. And, in earlier discussions on the Archer list, I agreed with this idea without giving it too much thought. But, that seems to me to be an empirical question. We could measure the impact. This would mean having some criteria for what is acceptable. I think that would probably be a good thing to have. It seems weird that the current status is that code goes into gdbserver without any sort of measurement impact -- if resources are an issue, then they should be an issue generally, not just due to the specter of C++. Pedro> (On a sidenote: I get the impression from some that C++ would be mostly Pedro> useful for the stronger static typing, but I can't help finding it in Pedro> contrast with the simultaneous push of some of GDB functionality towards Pedro> being implemented in python, with duck typing and all, which people Pedro> are happy with. The two programming environments are very different, though; and the core-versus-extension difference is essential. One thing I like about scripting gdb in Python is that I can write quickly -- but also that I can write lower-quality code without caring about it. Pedro> One (uninvestigated) idea I had was to take a look at Linux's Pedro> sparse tool for catching issues like the "offsets" case that led Pedro> to this thread.) For the offsets case it might have worked; but in many interesting cases static analysis (and thus modification) of gdb is just crazily hard, because gdb is written in such a weird way. E.g., read the Coverity reports sometime -- tons and tons of false reports due to cleanups. Cleanups are hard to even check when you write a tool specifically for checking them (I did this...). They are also what will make it very difficult for us to use the Python refcount checker (we probably just won't). Pedro> There's also the issue with in-process code, which is also Pedro> desirable to remain as C code. Latest developments push towards Pedro> having debugger code run _within_ the inferior. Witness Pedro> gdbserver's current IPA (in-process agent; libinproctrace.so), Pedro> which has a lot of coupling in its implementation (and a lot of Pedro> code shared), and a bunch of code shared with gdbserver. We Pedro> can't predict which bits of GDB will we want to be able to reuse Pedro> in GDBserver or an IPA, but I do believe that we will be Pedro> considering it (reuse something more) the future. It seems to me that we must have a licensing issue here. Can it really be ok to map GPL'd code into any old process? It seems mildly absurd to me to couple the implementation language choice of a large, complicated, interactive host-side tool like gdb to that of an in-process debug agent. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Can it really be ok to map GPL'd code into any old process? 2012-04-18 20:11 ` Tom Tromey @ 2012-04-18 20:31 ` John Gilmore 2012-04-18 20:36 ` Pedro Alves 2012-04-23 18:03 ` Will therefore GDB utilize C++ or not? Tom Tromey 1 sibling, 1 reply; 116+ messages in thread From: John Gilmore @ 2012-04-18 20:31 UTC (permalink / raw) To: Tom Tromey; +Cc: Pedro Alves, Jan Kratochvil, gdb > It seems to me that we must have a licensing issue here. > Can it really be ok to map GPL'd code into any old process? I think you can map it without trouble (just as you can mmap a text file into a process address space, regardless of its copyright). Or GDB can mmap a propriatary executable into its address space in order to read its symbols, read or patch its object code, or run it in a simulator. The problem, if any, is that you can't *link* GPL code to proprietary code (except system libraries). FSF took the position (with NeXT) that you can't even do that dynamically, if your goal is to circumvent the GPL (which WAS NeXT's goal). Ultimately it isn't up to FSF to decide what copyright law allows you to do -- it's the courts that would figure out whether linking or mmap-ing GPL'd code to proprietary code produces a derived work (and thus one whose copyright is derived from the copyright on the GPL'd code). So far I think it's pretty clear that static linking produces a derived work. I don't think the courts have ruled about dynamic linking. John ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Can it really be ok to map GPL'd code into any old process? 2012-04-18 20:31 ` Can it really be ok to map GPL'd code into any old process? John Gilmore @ 2012-04-18 20:36 ` Pedro Alves 0 siblings, 0 replies; 116+ messages in thread From: Pedro Alves @ 2012-04-18 20:36 UTC (permalink / raw) To: John Gilmore; +Cc: Tom Tromey, Jan Kratochvil, gdb On 04/18/2012 09:30 PM, John Gilmore wrote: >> It seems to me that we must have a licensing issue here. >> Can it really be ok to map GPL'd code into any old process? The IPA can also be injected into the target program with LD_PRELOAD. The user doesn't have to distribute the result, and indeed that would be shady area. But I think just using it like that falls into freedom 0. IANAL, and all that. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 20:11 ` Tom Tromey 2012-04-18 20:31 ` Can it really be ok to map GPL'd code into any old process? John Gilmore @ 2012-04-23 18:03 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-04-23 18:03 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb Tom> I think this relies on the idea that the C++ runtime dependency is Tom> unavoidably very heavy. And, in earlier discussions on the Archer list, Tom> I agreed with this idea without giving it too much thought. Tom> But, that seems to me to be an empirical question. We could measure the Tom> impact. Today I built gdbserver a number of different ways. In particular, I applied a few hacks, disabled all warnings, and used -fpermissive, so that I could build it with g++ as well. I'm appending my script, I can send the various hacks too if anybody needs them. They were trivial though. Here's the results. I did all builds on an x86-64 F16 box. For g++ I used -static-libstdc++; though it shouldn't pull in very much right now. I used a trunk gcc from today, since F16 doesn't apparently package libstdc++.a, but earlier runs with the system compiler were roughly similar. I threw in -fexceptions since I was curious what would happen. 344064 g++ -O2 331776 gcc -fexceptions -O2 331776 gcc -O2 311296 g++ -flto -O2 303104 g++ -Os 303104 gcc -flto -fexceptions -O2 303104 gcc -flto -O2 290816 gcc -fexceptions -Os 290816 gcc -Os 278528 g++ -flto -Os 270336 gcc -flto -fexceptions -Os 270336 gcc -flto -Os First, clearly, if you care about size you should be using -flto -Os. This is a clear win. Our default of -O2 is much worse. Second, g++ induces very little bloat on the current code base. It is about 3%. Now, I realize this is not necessarily indicative of the ultimate size increase. "Zero-cost" exceptions do in fact have a cost in the size of the executable. I failed to easily build an SJLJ compiler, so I didn't try to do any measurements of this. This process did discover a bad "return 1" in the middle of ax.c:gdb_eval_agent_expr. I think it should return expr_eval_unrecognized_opcode. Tom #!/bin/sh for comp in gcc g++; do if test $comp = gcc; then cc=$comp compflags= else cc='g++ -fpermissive' compflags='LDFLAGS=-static-libstdc++' fi for base in '' -flto; do for exc in '' -fexceptions; do if test $comp = g++ && test x$exc = x-fexceptions; then continue fi for opts in -O2 -Os; do echo ================================================================ flags=$(echo $base $exc $opts) echo ===== $flags echo make clean-local make CC="$cc" CFLAGS="$flags" WARN_CFLAGS= WERROR_CFLAGS= $compflags gdbserver f2=$(echo $comp $flags | sed -e 's/ /_/g') cp gdbserver gdbserver-$f2 done done done done ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 18:41 ` Pedro Alves ` (2 preceding siblings ...) 2012-04-18 20:11 ` Tom Tromey @ 2012-05-18 19:55 ` Tom Tromey 2012-05-18 21:56 ` Joel Brobecker 2012-05-21 15:56 ` Pedro Alves 2012-11-22 18:46 ` Jan Kratochvil 4 siblings, 2 replies; 116+ messages in thread From: Tom Tromey @ 2012-05-18 19:55 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb >>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes: Pedro> This is important, because we want gdbserver to be usable in #1, Pedro> resource constrained scenarios where the C++ dependency would be Pedro> unacceptable. I wonder whether you would reconsider this given the size measurements I did. In particular, C++ is something like 3% space overhead today, and that gdbserver is already ~300K. I think that size growth is quite acceptable. Pedro> We don't want there to need to be other gdbserver-like programs Pedro> specialized for such environments, and gdbserver to be usable Pedro> only on bigger machines. We want gdbserver to run everywhere. The recent gdb-patches thread from Jonathan Larmour indicates that we already lost this one. He was concerned about the use of 2183 bytes. Pedro> And #2, the debugger is one of the first programs that is Pedro> desirable to get running on a new system/board. Usually you get Pedro> C going much sooner than C++. I think there are multiple options for this scenario. People could start with a basic port of RDA, or an older gdbserver, or just bump up the priority of getting C++ working. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 19:55 ` Tom Tromey @ 2012-05-18 21:56 ` Joel Brobecker 2012-05-19 2:17 ` Tom Tromey 2012-05-20 12:16 ` Frank Ch. Eigler 2012-05-21 15:56 ` Pedro Alves 1 sibling, 2 replies; 116+ messages in thread From: Joel Brobecker @ 2012-05-18 21:56 UTC (permalink / raw) To: Tom Tromey; +Cc: Pedro Alves, Jan Kratochvil, gdb > Pedro> And #2, the debugger is one of the first programs that is > Pedro> desirable to get running on a new system/board. Usually you get > Pedro> C going much sooner than C++. > > I think there are multiple options for this scenario. People could > start with a basic port of RDA, or an older gdbserver, or just bump up > the priority of getting C++ working. I would really like us to avoid making GDBserver a C++ program. I said in the past that I was concerned that making GDB a C++ program would make it less accessible on the less used platforms. But I am ready to accept that constraint to build GDB if it can help general development. For GDBserver, however, which is often cross-compiled to bare systems, I feel that getting a C++ compiler could be even more challenging that on those exotic but otherwise relatively rich platforms. -- Joel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 21:56 ` Joel Brobecker @ 2012-05-19 2:17 ` Tom Tromey 2012-05-19 15:21 ` Daniel Jacobowitz 2012-05-20 12:16 ` Frank Ch. Eigler 1 sibling, 1 reply; 116+ messages in thread From: Tom Tromey @ 2012-05-19 2:17 UTC (permalink / raw) To: Joel Brobecker; +Cc: Pedro Alves, Jan Kratochvil, gdb >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: Joel> For GDBserver, however, which is often cross-compiled to bare Joel> systems, I feel that getting a C++ compiler could be even more Joel> challenging that on those exotic but otherwise relatively rich Joel> platforms. Ok. I think in that case we must drop this idea. That's too bad, but I guess we will soldier on. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-19 2:17 ` Tom Tromey @ 2012-05-19 15:21 ` Daniel Jacobowitz 2012-05-19 21:36 ` Joel Brobecker 0 siblings, 1 reply; 116+ messages in thread From: Daniel Jacobowitz @ 2012-05-19 15:21 UTC (permalink / raw) To: Tom Tromey; +Cc: Joel Brobecker, Pedro Alves, Jan Kratochvil, gdb On Fri, May 18, 2012 at 10:17 PM, Tom Tromey <tromey@redhat.com> wrote: > > >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: > > Joel> For GDBserver, however, which is often cross-compiled to bare > Joel> systems, I feel that getting a C++ compiler could be even more > Joel> challenging that on those exotic but otherwise relatively rich > Joel> platforms. > > Ok. > > I think in that case we must drop this idea. For the record, I stand by my earlier messages in this thread about code sharing with gdbserver; I think there is plenty of room for a C gdbserver and a C++ one, and the times when C++ doesn't work on your target are definitely times when you prefer the simplest possible and most bulletproof gdbserver. What I'd really love to see, in C or C++, would be unit testing; having worked in a unit test intensive environment for the past year, I think it's a bit nuts that anyone *doesn't*. It seems to me that there are better tools for this in C++ than in C, but I have definitely not done a serious investigation of the options. -- Thanks, Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-19 15:21 ` Daniel Jacobowitz @ 2012-05-19 21:36 ` Joel Brobecker 0 siblings, 0 replies; 116+ messages in thread From: Joel Brobecker @ 2012-05-19 21:36 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Tom Tromey, Pedro Alves, Jan Kratochvil, gdb > For the record, I stand by my earlier messages in this thread about > code sharing with gdbserver; I think there is plenty of room for a C > gdbserver and a C++ one, and the times when C++ doesn't work on your > target are definitely times when you prefer the simplest possible and > most bulletproof gdbserver. I wouldn't mind something like this either. I don't have much of an idea of what optional features could be better implemented in C++, though, given the fact that GDBserver is a very small piece of code as it is... But that's easy to discuss some other day if someone wants to take that project further. > What I'd really love to see, in C or C++, would be unit testing; > having worked in a unit test intensive environment for the past year, > I think it's a bit nuts that anyone *doesn't*. It seems to me that > there are better tools for this in C++ than in C, but I have > definitely not done a serious investigation of the options. I agree. For one thing, it would allow us to test the observers without have to go through debugging GDB with GDB and make inferior function calls. As an aside, I used to work on an Air Traffic Control system, and did a lot of Unit Testing and Deep Unit Testing. I know from this experience that this is time and effort well invested, and I tend to use them for my own projects as well. -- Joel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 21:56 ` Joel Brobecker 2012-05-19 2:17 ` Tom Tromey @ 2012-05-20 12:16 ` Frank Ch. Eigler 1 sibling, 0 replies; 116+ messages in thread From: Frank Ch. Eigler @ 2012-05-20 12:16 UTC (permalink / raw) To: Joel Brobecker; +Cc: Tom Tromey, Pedro Alves, Jan Kratochvil, gdb Joel Brobecker <brobecker@adacore.com> writes: > [...] GDBserver, however, which is often cross-compiled to bare > systems, I feel that getting a C++ compiler could be even more > challenging that on those exotic but otherwise relatively rich > platforms. Could y'all embrace a minimal gdbserver for cross-compilation bringup purposes, instead of holding back relatively rich working platforms? http://sourceware.org/rda/ et al., maybe connected tighter to the gdb build system? - FChE ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-18 19:55 ` Tom Tromey 2012-05-18 21:56 ` Joel Brobecker @ 2012-05-21 15:56 ` Pedro Alves 2012-05-21 16:15 ` Jan Kratochvil 2012-05-26 15:50 ` Jan Kratochvil 1 sibling, 2 replies; 116+ messages in thread From: Pedro Alves @ 2012-05-21 15:56 UTC (permalink / raw) To: Tom Tromey; +Cc: Jan Kratochvil, gdb On 05/18/2012 08:55 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes: > > Pedro> This is important, because we want gdbserver to be usable in #1, > Pedro> resource constrained scenarios where the C++ dependency would be > Pedro> unacceptable. > > I wonder whether you would reconsider this given the size measurements I > did. Thanks. I appreciate them. I didn't expect the code size to grow significantly, as we had already seem similar comparisons done for gcc in the course of the various C vs C++ discussions over there with similar results. However, I'll note that such comparisons assume an unchanged C-style codebase, and ignore the size increase you get when you actually start using C++ features, such as, throwing exceptions, or using iostream. In my quick experiment adding a cout << "foo" (-static-libstdc++ -flto -Os + strip) more than triples the binary size. > In particular, C++ is something like 3% space overhead today, and that > gdbserver is already ~300K. I think that size growth is quite > acceptable. > > Pedro> We don't want there to need to be other gdbserver-like programs > Pedro> specialized for such environments, and gdbserver to be usable > Pedro> only on bigger machines. We want gdbserver to run everywhere. > > The recent gdb-patches thread from Jonathan Larmour indicates that we > already lost this one. He was concerned about the use of 2183 bytes. That was for eCos, running on tiny embedded micro-controllers though. I'm talking about things such as uclinux based routers vs big iron GNU/Linux mainframes -- having only one codebase to maintain that has to know ptrace intricasy, for example. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 15:56 ` Pedro Alves @ 2012-05-21 16:15 ` Jan Kratochvil 2012-05-21 17:37 ` Paul_Koning 2012-05-21 18:08 ` Pedro Alves 2012-05-26 15:50 ` Jan Kratochvil 1 sibling, 2 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-05-21 16:15 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote: > In my quick experiment adding a cout << "foo" (-static-libstdc++ -flto -Os > + strip) more than triples the binary size. Could you give specific still used device example where the current codebase is OK while the triple gdbserver size is no longer OK? All the discussions are still very abstract. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 16:15 ` Jan Kratochvil @ 2012-05-21 17:37 ` Paul_Koning 2012-05-21 17:58 ` Jan Kratochvil 2012-05-21 18:08 ` Pedro Alves 1 sibling, 1 reply; 116+ messages in thread From: Paul_Koning @ 2012-05-21 17:37 UTC (permalink / raw) To: jan.kratochvil; +Cc: palves, tromey, gdb I'm working on a system where the boot device has about a megabyte free space, on a good day. paul On May 21, 2012, at 12:14 PM, Jan Kratochvil wrote: > On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote: >> In my quick experiment adding a cout << "foo" (-static-libstdc++ -flto -Os >> + strip) more than triples the binary size. > > Could you give specific still used device example where the current codebase > is OK while the triple gdbserver size is no longer OK? All the discussions > are still very abstract. > > > Thanks, > Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 17:37 ` Paul_Koning @ 2012-05-21 17:58 ` Jan Kratochvil 2012-05-22 18:03 ` Paul_Koning 0 siblings, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-05-21 17:58 UTC (permalink / raw) To: Paul_Koning; +Cc: palves, tromey, gdb On Mon, 21 May 2012 19:36:57 +0200, Paul_Koning@Dell.com wrote: > I'm working on a system where the boot device has about a megabyte free > space, on a good day. Which arch/os is that (to guess the gdbserver size differences)? Is some secondary storage really unavailable? How much simple gdbserver would be enough - for example do you need threading in that stage? Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 17:58 ` Jan Kratochvil @ 2012-05-22 18:03 ` Paul_Koning 0 siblings, 0 replies; 116+ messages in thread From: Paul_Koning @ 2012-05-22 18:03 UTC (permalink / raw) To: jan.kratochvil; +Cc: palves, tromey, gdb It's a NetBSD/MIPS64 derivative embedded system. No other secondary storage for code. Threading support is needed. (That doesn't add much.) I don't currently have multi-inferior support, although I've thought about adding that. paul On May 21, 2012, at 1:57 PM, Jan Kratochvil wrote: > On Mon, 21 May 2012 19:36:57 +0200, Paul_Koning@Dell.com wrote: >> I'm working on a system where the boot device has about a megabyte free >> space, on a good day. > > Which arch/os is that (to guess the gdbserver size differences)? Is some > secondary storage really unavailable? How much simple gdbserver would be > enough - for example do you need threading in that stage? > > > Thanks, > Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 16:15 ` Jan Kratochvil 2012-05-21 17:37 ` Paul_Koning @ 2012-05-21 18:08 ` Pedro Alves 2012-05-21 18:08 ` Tom Tromey ` (2 more replies) 1 sibling, 3 replies; 116+ messages in thread From: Pedro Alves @ 2012-05-21 18:08 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Tom Tromey, gdb On 05/21/2012 05:14 PM, Jan Kratochvil wrote: > On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote: >> In my quick experiment adding a cout << "foo" (-static-libstdc++ -flto -Os >> + strip) more than triples the binary size. > > Could you give specific still used device example where the current codebase > is OK while the triple gdbserver size is no longer OK? All the discussions > are still very abstract. I should point out that that question is a bit backwards. If you can shrink the storage to save costs, you'll do it. But obviously you won't shrink more than what necessary to run your software. That - shrink storage - is the reasoning why e.g., one feature eglibc has over glibc, is a way to configure out things that may not be needed on an embedded system. Google around for OpenWrt or DD-WRT for example, to find configurations where 4-32MB flash is common. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 18:08 ` Pedro Alves @ 2012-05-21 18:08 ` Tom Tromey 2012-05-21 18:10 ` Jan Kratochvil 2012-05-21 18:54 ` Matt Rice 2 siblings, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-05-21 18:08 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb Jan> Could you give specific still used device example where the current Jan> codebase is OK while the triple gdbserver size is no longer OK? Jan> All the discussions are still very abstract. Pedro> I should point out that that question is a bit backwards. If you can Pedro> shrink the storage to save costs, you'll do it. But obviously you won't Pedro> shrink more than what necessary to run your software. If size is a critical argument against C++, then it has to be a critical argument in other cases as well. I think it is important for us to establish the desirable bounds on the size of gdbserver, so that we can request this data in future gdbserver patch reviews. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 18:08 ` Pedro Alves 2012-05-21 18:08 ` Tom Tromey @ 2012-05-21 18:10 ` Jan Kratochvil 2012-05-21 18:54 ` Matt Rice 2 siblings, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-05-21 18:10 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Mon, 21 May 2012 18:52:09 +0200, Pedro Alves wrote: > But obviously you won't shrink more than what necessary to run your > software. Proposed C++ is not a clear win-win, it is a compromise. I have found this discussion gives enough reasons (~from Tom) to consider C++ "very important". The size has some importance but these mails try to decide whether the size regressions is globally as important as the C++ benefits for GDB or not. If the size is important enough then there is also the alternative gdbserver for bootstraps without C++ (older FSF gdbserver, RDA, #ifdef-out-ed HEAD FSF gdbserver etc.). It has also various disadvantages but again I consider them globally less important than the C++ benefits for GDB. > Google around for OpenWrt or DD-WRT for example, to find configurations > where 4-32MB flash is common. This is not the specific enough answer I was asking for. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 18:08 ` Pedro Alves 2012-05-21 18:08 ` Tom Tromey 2012-05-21 18:10 ` Jan Kratochvil @ 2012-05-21 18:54 ` Matt Rice 2 siblings, 0 replies; 116+ messages in thread From: Matt Rice @ 2012-05-21 18:54 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, Tom Tromey, gdb On Mon, May 21, 2012 at 9:52 AM, Pedro Alves <palves@redhat.com> wrote: > > Google around for OpenWrt or DD-WRT for example, to find configurations > where 4-32MB flash is common. FWIW, I have an openwrt install on a 4MB flash, and figuring out how to find enough space for the existing gdbserver was a pain. to the point where I just made a ramdisk and copied gdbserver to it when i needed it (which lucky for me wasn't debugging any issue at boot time/user space worked enough to get gdbserver to its destination.) many of these newer openwrt/dd-wrt systems also have usb they can use to add additional storage. that is to say, i think regardless of c/c++ gdbserver is possibly too big for some of these small but not tiny installations or at least on the cusp of being so, and getting larger, thus a smaller gdbserver might be warranted regardless of c/c++ ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-21 15:56 ` Pedro Alves 2012-05-21 16:15 ` Jan Kratochvil @ 2012-05-26 15:50 ` Jan Kratochvil 2012-06-02 7:01 ` Russell Shaw 1 sibling, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-05-26 15:50 UTC (permalink / raw) To: Pedro Alves, Paul_Koning; +Cc: Tom Tromey, gdb On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote: > However, I'll note that such comparisons assume an unchanged C-style codebase, > and ignore the size increase you get when you actually start using C++ > features, such as, throwing exceptions, or using iostream. In my quick > experiment adding a cout << "foo" (-static-libstdc++ -flto -Os + strip) more > than triples the binary size. FSF GDB HEAD plain C build: x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease) linux-vdso.so.1 => (0x00007fff4b093000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fb835780000) libc.so.6 => /lib64/libc.so.6 (0x00007fb8353c8000) /lib64/ld-linux-x86-64.so.2 (0x00007fb835994000) -rwxr-xr-x 1 jkratoch jkratoch 265000 May 26 16:05 gdbserver* After adding that cout I really get ~1.1MB bytes build. But iostream is not useful for gdbserver. With the useful C++ features exploited by #include <vector> #include <unordered_map> #include <string> { unordered_map<string, string> foo; foo["bar"] = "b"; vector<string> bar; try { throw 0; } catch (int e) { bar.push_back(string("bar")); } } I get: x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease) linux-vdso.so.1 => (0x00007fff084b5000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fa35d6e8000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa35d3e4000) libm.so.6 => /lib64/libm.so.6 (0x00007fa35d0e9000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa35ced4000) libc.so.6 => /lib64/libc.so.6 (0x00007fa35cb1c000) /lib64/ld-linux-x86-64.so.2 (0x00007fa35d8fc000) -rwxr-xr-x 1 jkratoch jkratoch 285816 May 26 16:50 gdbserver* With linking statically the additional libraries the C build has not depended upon: x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease) linux-vdso.so.1 => (0x00007fffee9ff000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f54fbf07000) libc.so.6 => /lib64/libc.so.6 (0x00007f54fbb4f000) /lib64/ld-linux-x86-64.so.2 (0x00007f54fc11b000) -rwxr-xr-x 1 jkratoch jkratoch 453728 May 26 17:22 gdbserver* 453728 vs. 265000 bytes is +71% increase. It still seems perfectly worth to me for all the discussed C++ benefits for GDB. (Maybe one could also look for some inadvertent libraries parts brought in.) On Tue, 22 May 2012 20:03:41 +0200, Paul_Koning@Dell.com wrote: > > On Mon, 21 May 2012 19:36:57 +0200, Paul_Koning@Dell.com wrote: > > > I'm working on a system where the boot device has about a megabyte free > > > space, on a good day. > It's a NetBSD/MIPS64 derivative embedded system. No other secondary storage > for code. I have used gcc42.fsffrance.org producing: gdbserver: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped FSF GDB HEAD plain C build: mips32 -Os gcc (RAYS 4.3.0-4.rays0) 4.3.1 20080501 (prerelease) libdl.so.2 => /lib/libdl.so.2 (0x2aaec000) libc.so.6 => /lib/libc.so.6 (0x2ab00000) /lib/ld.so.1 (0x2aaa8000) -rwxr-xr-x 1 jankratochvil jankratochvil 306092 2012-05-26 05:12 gdbserver* With the <vector>/<unordered_map>/<string> C++ features I get: libdl.so.2 => /lib/libdl.so.2 (0x2aaec000) libc.so.6 => /lib/libc.so.6 (0x2ab00000) /lib/ld.so.1 (0x2aaa8000) -rwxr-xr-x 1 jankratochvil jankratochvil 846668 2012-05-26 17:44 gdbserver* The size increase is primarily due to libm.a, with libm.so I get: libdl.so.2 => /lib/libdl.so.2 (0x2aaec000) libm.so.6 => /lib/libm.so.6 (0x2ab00000) libc.so.6 => /lib/libc.so.6 (0x2ab98000) /lib/ld.so.1 (0x2aaa8000) -rwxr-xr-x 1 jankratochvil jankratochvil 462188 2012-05-26 17:41 gdbserver* I believe we can get mips under 500KB as libm should not be needed anywhere. For 64-bit mips64: When I used CFLAGS="-Os -mips64 -mabi=64" there producing: gdbserver: ELF 64-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped I did not have static 64-bit libstdc++ available on gcc42.fsffrance.org. I had some issues building mips64 toolchain and I did not spend too much time on it. 64-bit libstdc++.so would work but it would not provide the size benchmark numbers here. 64-bit FSF GDB HEAD gdbserver was 289496 bytes (instead of 32-bit 306092) so 64-bit mips build size numbers should not be in disadvantage. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-05-26 15:50 ` Jan Kratochvil @ 2012-06-02 7:01 ` Russell Shaw 2012-06-02 7:13 ` Jan Kratochvil 0 siblings, 1 reply; 116+ messages in thread From: Russell Shaw @ 2012-06-02 7:01 UTC (permalink / raw) Cc: gdb On 27/05/12 01:50, Jan Kratochvil wrote: > On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote: ... > 453728 vs. 265000 bytes is +71% increase. > It still seems perfectly worth to me for all the discussed C++ benefits for GDB. ... A few of the things i didn't like about C++ have been fixed in the C++11 standard. In particular, under: Rvalue references and move constructors <http://en.wikipedia.org/wiki/C%2B%2B11#Rvalue_references_and_move_constructors> A lot of C++ code was copying objects by value, which means the copy constructor had to deep-copy and malloc to make temporaries, only to throw them away later. That is *slow* and fragments the heap, especially on smaller systems. With C11, new "move constructors" have been added for copying malloc'd memory to avoid that problem. Parsing C++ has also been improved. <http://en.wikipedia.org/wiki/Most_vexing_parse> A lot of other improvements too. I just read the C11 standard (close to final version), and am re-considering the use of C++ for smaller microcontrollers. If gdb is done in C++, run-time performance and bloat should be kept in check by avoiding gratuitous use of generalized template libraries. C-like libraries for things like bit-sets and symbol tables should work equally as efficient in C++ if translated with some superficial C++ syntax. Hitting my F9 "compile" button would result in an annoying half-second delay when compiling simple programs using the STL (years ago when i did C++). Self written utility libraries such as those already done in C in gdb could avoid that. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-06-02 7:01 ` Russell Shaw @ 2012-06-02 7:13 ` Jan Kratochvil 2012-06-02 10:47 ` Russell Shaw 0 siblings, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-06-02 7:13 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, 02 Jun 2012 09:01:03 +0200, Russell Shaw wrote: > Hitting my F9 "compile" button would result in an annoying > half-second delay when compiling simple programs using the STL > (years ago when i did C++). Self written utility libraries such as > those already done in C in gdb could avoid that. Saving that half-second discourages contributors by using non-standard libraries for the same basic functionality they already know well from C++. Regards, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-06-02 7:13 ` Jan Kratochvil @ 2012-06-02 10:47 ` Russell Shaw 2012-06-02 11:10 ` Jan Kratochvil 0 siblings, 1 reply; 116+ messages in thread From: Russell Shaw @ 2012-06-02 10:47 UTC (permalink / raw) Cc: gdb On 02/06/12 17:13, Jan Kratochvil wrote: > On Sat, 02 Jun 2012 09:01:03 +0200, Russell Shaw wrote: >> Hitting my F9 "compile" button would result in an annoying >> half-second delay when compiling simple programs using the STL >> (years ago when i did C++). Self written utility libraries such as >> those already done in C in gdb could avoid that. > > Saving that half-second discourages contributors by using non-standard > libraries for the same basic functionality they already know well from C++. A friend said when he was using the full STL, the delay was 8 seconds. It's completely intolerable when one is used to incremental editing/compiling/running with instant C compilations. Wouldn't there be far more existing GDB contributors that would understand C++'ified gdb libraries, than C++ coders that know anything about the internals of gdb? General STL libraries could be ok to a degree, where there is little performance or resource impact, and where it simplifies current code. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-06-02 10:47 ` Russell Shaw @ 2012-06-02 11:10 ` Jan Kratochvil 2012-06-02 11:15 ` Russell Shaw 2012-06-02 11:15 ` Jan Kratochvil 0 siblings, 2 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-06-02 11:10 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, 02 Jun 2012 12:47:22 +0200, Russell Shaw wrote: > A friend said when he was using the full STL, the delay was 8 seconds. This is too vague claim. Which hardware he used? Why was full STL used by a single CU? Was he using gold? And its incremental linking? > Wouldn't there be far more existing GDB contributors that would > understand C++'ified gdb libraries, than C++ coders that know > anything about the internals of gdb? It is a good question, my assumptions sure may be wrong. Regards, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-06-02 11:10 ` Jan Kratochvil @ 2012-06-02 11:15 ` Russell Shaw 2012-06-02 11:15 ` Jan Kratochvil 1 sibling, 0 replies; 116+ messages in thread From: Russell Shaw @ 2012-06-02 11:15 UTC (permalink / raw) Cc: gdb On 02/06/12 21:10, Jan Kratochvil wrote: > On Sat, 02 Jun 2012 12:47:22 +0200, Russell Shaw wrote: >> A friend said when he was using the full STL, the delay was 8 seconds. > > This is too vague claim. Which hardware he used? Why was full STL used by > a single CU? Was he using gold? And its incremental linking? I don't know. The fact that it can happen is just something to be aware of. He was using in a mingw or whatever environment on a windows XP box which probably doesn't help either. >> Wouldn't there be far more existing GDB contributors that would >> understand C++'ified gdb libraries, than C++ coders that know >> anything about the internals of gdb? > > It is a good question, my assumptions sure may be wrong. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-06-02 11:10 ` Jan Kratochvil 2012-06-02 11:15 ` Russell Shaw @ 2012-06-02 11:15 ` Jan Kratochvil 1 sibling, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-06-02 11:15 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, 02 Jun 2012 13:10:19 +0200, Jan Kratochvil wrote: > On Sat, 02 Jun 2012 12:47:22 +0200, Russell Shaw wrote: > > Wouldn't there be far more existing GDB contributors that would > > understand C++'ified gdb libraries, than C++ coders that know > > anything about the internals of gdb? > > It is a good question, my assumptions sure may be wrong. If not clear this is a question about how heavy usage of STL there should be. There is still worth C++ at least just the fixes of crashes from the GDB cleanups system. Regards, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 18:41 ` Pedro Alves ` (3 preceding siblings ...) 2012-05-18 19:55 ` Tom Tromey @ 2012-11-22 18:46 ` Jan Kratochvil 2012-11-22 21:42 ` John Gilmore 2012-11-27 1:29 ` Stan Shebs 4 siblings, 2 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-11-22 18:46 UTC (permalink / raw) To: Pedro Alves; +Cc: Tom Tromey, gdb On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: > If you asked me not too long ago, I'd have been strongly in favor > of C++. However, that is no longer the case. I'm now pending > towards "no C++". I have re-read now the thread and I have not found any blocker issues left. Here is a plan that should IMHO satisfy all the requirements stated here. I did not reply to C++ disagreements which were already well enough replied here. Current gdbserver will be also in C++. For most embedded Linux kernel targets it will be enough to build the standard fully featured gdbserver with static libstdc++ (making it only ~2x larger). There will be also separate minimal gdbserver in plain C. For some very minimal targets still running Linux kernel but no longer having C++-capable compiler or having some other problem running C++. There was stated no concrete such target but maybe there exists one. This minimal server has no need for non-stop/multi-inferior etc., it will be created by stripping down the current one; but in fact one can be also easily code it from scratch. libinproctrace.so will remain in C so far. I do not think this sole reason should block the GDB + gdbserver move to C++. In the future I believe it can move to statically built libstdc++ without problem. It will never be supported on the minimal C gdbserver which also is not a problem. There should be provided a list of systems GDB needs to remain compatible with and which are available for login directly or which can be at least promptly regression tested upon request. As could be seen for example on Solaris recently the compatibility with a system which GDB is not tested against will break. The compatibility is not kept automatically just thanks to the reviews. Then we can find out the minimal C++ level can be required. I assume some -std=c++98 with a bundled subset of Boost should be OK. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-11-22 18:46 ` Jan Kratochvil @ 2012-11-22 21:42 ` John Gilmore 2012-11-23 15:26 ` Jan Kratochvil 2012-11-27 1:29 ` Stan Shebs 1 sibling, 1 reply; 116+ messages in thread From: John Gilmore @ 2012-11-22 21:42 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pedro Alves, Tom Tromey, gdb > For most embedded Linux kernel targets it will be enough to build the standard > fully featured gdbserver with static libstdc++ (making it only ~2x larger). It becomes ~2x larger for what benefit? > There will be also separate minimal gdbserver in plain C. > ... This minimal server has no > need for non-stop/multi-inferior etc., it will be created by stripping down > the current one; but in fact one can be also easily code it from scratch. Why in heaven's name would you take working code that's in the release today, and "strip it down" to be less functional? What's wrong with continuing to ship it merely the way it is? John ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-11-22 21:42 ` John Gilmore @ 2012-11-23 15:26 ` Jan Kratochvil 0 siblings, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-11-23 15:26 UTC (permalink / raw) To: John Gilmore; +Cc: Pedro Alves, Tom Tromey, gdb On Thu, 22 Nov 2012 22:42:42 +0100, John Gilmore wrote: > > For most embedded Linux kernel targets it will be enough to build the standard > > fully featured gdbserver with static libstdc++ (making it only ~2x larger). > > It becomes ~2x larger for what benefit? http://sourceware.org/ml/gdb/2012-04/msg00044.html Specifically the size of code itself is irrelevant. It may have rather other disadvantages such as clearly lower compatibility with compilers. Not that it would be a problem nowadays on GDB supported platforms. > > There will be also separate minimal gdbserver in plain C. > > ... This minimal server has no > > need for non-stop/multi-inferior etc., it will be created by stripping down > > the current one; but in fact one can be also easily code it from scratch. > > Why in heaven's name would you take working code that's in the release > today, and "strip it down" to be less functional? What's wrong with > continuing to ship it merely the way it is? Because the advanced features (non-stop/multi-inferior etc.) are still not fully stable, their require more fixes and extensions. Coincidentally these features are not required on the very few target platforms possibly not supporting C++ for gdbserver. One option is to use existing C gdbserver as is on those few non-C++ target platforms. But if anyone tries to use some advanced feature there s/he may face bugs/incompatibilities in those. Therefore I believe it is easier for everyone not to ship broken and unmaintained features at all. The other option of keeping gdbserver in C faces the problem it could no longer share significant code parts with gdb. Problems from such design were described by Pedro as not feasible: http://sourceware.org/ml/gdb/2012-04/msg00063.html I was always against C++ till and including first years od GDB, this is why I always preferred GTK with its C++-in-C GObject framework compared to Qt. The reasons in my case were: * Compiler incompatibility, around 2000 C++ across GCC and compilers on commercial Unices was not compatible. AFAIK C++ standardization is now OK and also the set of compilers/platforms in use is reduced compared to 2000. * Debugging C++ was a problem as GDB did not handle it well. It has improved a lot and besides that the remaining issues will get fixed faster with GDB in C++. * That "tables of C pointers" as in GObject is good enough replacement for C++. That was a misunderstand what is C++, virtual method table is a negligible part of what provides C++ and its STL/Boost libraries. I do not want to start showing how easier are C constructs when written in a proper way in C++, one such was already posted here with shared_ptr: http://sourceware.org/ml/gdb/2012-11/msg00063.html Although that was still overcomplicated to match Pedro's real pointer in the former code. Usually one can keep and pass the variable by value (with no shared_ptr) thanks to the move constructor efficiency. The repeating simple crasher bugs just due to the C++-in-C GDB framework which is only reviewer checked and not compiler checked is too fragile. You can takeover fixing all these annoying crasher bugs like: https://bugzilla.redhat.com/show_bug.cgi?id=864575 Fortunately compilers have evolved during the years and what had to be verified by hand can be now automated by the compiler. There are still bugs in the programs but people can spend more time fixing the bugs not caught by the compiler instead of doing the same what the compiler does automatically. While not the typical C++ purpose specifically now (again) I push for C++ because I have to upstream the 64-bit inferior offsets/sizes as present in many patches posted by Siddhesh Poyarekar <siddhesh@redhat.com>. After almost the year of work we/I can start again as there no way for easy refactorization of C code. splint or compiler warnings were shown as incomplete for that purpose, fixing very every '-Wconversion -Wno-sign-conversion' warning is many times more expensive (than fixing just the cases requested to be fixed). With C++ one can provide container classes for the numerical types and catch just the operations violating the type width safety. #include <stdlib.h> class Type64 { private: int64_t v; operator int32_t () { abort (); } // error public: operator int64_t () { return v; } int64_t get () { return v; } Type64() {} Type64(int64_t i) { v = i; } Type64& operator = (const Type64 &rhs) { v = rhs.v; return *this; } Type64& operator ++ () { ++v; return *this; } Type64 operator ++ (int) { Type64 retval(*this); ++v; return retval; } Type64 operator += (const Type64 &rhs) { v += rhs.v; return *this; } }; int main () { Type64 v64 = 0; v64++; ++v64; v64 += 2; int error = v64; // error: ‘Type64::operator int32_t()’ is private return v64.get (); // safe explicit request for width violation } Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-11-22 18:46 ` Jan Kratochvil 2012-11-22 21:42 ` John Gilmore @ 2012-11-27 1:29 ` Stan Shebs 2012-11-27 2:02 ` Paul_Koning 1 sibling, 1 reply; 116+ messages in thread From: Stan Shebs @ 2012-11-27 1:29 UTC (permalink / raw) To: gdb On 11/22/12 10:46 AM, Jan Kratochvil wrote: > On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: >> If you asked me not too long ago, I'd have been strongly in favor >> of C++. However, that is no longer the case. I'm now pending >> towards "no C++". > I have re-read now the thread and I have not found any blocker issues left. > > Here is a plan that should IMHO satisfy all the requirements stated here. > I did not reply to C++ disagreements which were already well enough replied > here. > > > Current gdbserver will be also in C++. > > For most embedded Linux kernel targets it will be enough to build the standard > fully featured gdbserver with static libstdc++ (making it only ~2x larger). > > There will be also separate minimal gdbserver in plain C. For some very > minimal targets still running Linux kernel but no longer having C++-capable > compiler or having some other problem running C++. There was stated no > concrete such target but maybe there exists one. This minimal server has no > need for non-stop/multi-inferior etc., it will be created by stripping down > the current one; but in fact one can be also easily code it from scratch. > I think for this it should be sufficient to announce an end-of-C point for gdbserver, tag it, and record it on a web page; while it's certainly possible that someone in the future will have need for a C-only gdbserver, I think the chances are vanishingly small, and we shouldn't be using up too many brain cycles designing it. People that are space-conscious are already using their own stubs or forked versions of gdbserver. I note for instance that we nearly doubled the size of gdbserver's code when we added target-side tracepoint bits a couple years ago, and I don't recall any grousing about it getting too big then. In a world where mega-programs like Firefox fit easily onto a cell phone *now*, I'm not just seeing that any future projects are going to be so tightly constrained that gdbserver size is noticeable. Stan stan@codesourcery.com ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-11-27 1:29 ` Stan Shebs @ 2012-11-27 2:02 ` Paul_Koning 2012-11-27 2:59 ` Stan Shebs 0 siblings, 1 reply; 116+ messages in thread From: Paul_Koning @ 2012-11-27 2:02 UTC (permalink / raw) To: stanshebs; +Cc: gdb On Nov 26, 2012, at 8:29 PM, Stan Shebs wrote: > ... > People that are space-conscious are already using their own stubs or forked versions of gdbserver. I note for instance that we nearly doubled the size of gdbserver's code when we added target-side tracepoint bits a couple years ago, and I don't recall any grousing about it getting too big then. In a world where mega-programs like Firefox fit easily onto a cell phone *now*, I'm not just seeing that any future projects are going to be so tightly constrained that gdbserver size is noticeable. > > Stan > stan@codesourcery.com I guess I have to keep repeating it: multi-gigabyte cell phones are NOT examples of space constrained embedded systems. I'm working on an embedded system that's physically much larger but has only 64 MB for the program store, and only a gigabyte of memory -- of which only 128 MB is available for the OS and user mode processes. Yes, the stock gdbserver as delivered with GBD 7 is acceptable. No, doubling it in size is not something you can just casually propose and assume no one will object. And I know from previous discussions that the system I'm talking about is nowhere near the most space constrained of embedded systems under active development. So can we please stop this silly assumption that everyone has gigabytes to spare? Yes of course, if the GDB project starts to operate on the basis that space is no object, I can and will fork. But isn't the whole point of open source projects that, while forking is of course allowed, it isn't something to be pushed as the best way to use the project? If forking was such a wonderful thing, we'd still have EGCS. paul ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-11-27 2:02 ` Paul_Koning @ 2012-11-27 2:59 ` Stan Shebs 2012-11-27 15:17 ` Paul_Koning 2012-11-27 21:14 ` Tom Tromey 0 siblings, 2 replies; 116+ messages in thread From: Stan Shebs @ 2012-11-27 2:59 UTC (permalink / raw) To: Paul_Koning; +Cc: gdb On 11/26/12 6:02 PM, Paul_Koning@Dell.com wrote: > On Nov 26, 2012, at 8:29 PM, Stan Shebs wrote: >> ... >> People that are space-conscious are already using their own stubs or forked versions of gdbserver. I note for instance that we nearly doubled the size of gdbserver's code when we added target-side tracepoint bits a couple years ago, and I don't recall any grousing about it getting too big then. In a world where mega-programs like Firefox fit easily onto a cell phone *now*, I'm not just seeing that any future projects are going to be so tightly constrained that gdbserver size is noticeable. >> >> Stan >> stan@codesourcery.com > I guess I have to keep repeating it: multi-gigabyte cell phones are NOT examples of space constrained embedded systems. I'm working on an embedded system that's physically much larger but has only 64 MB for the program store, and only a gigabyte of memory -- of which only 128 MB is available for the OS and user mode processes. > > Yes, the stock gdbserver as delivered with GBD 7 is acceptable. No, doubling it in size is not something you can just casually propose and assume no one will object. > > And I know from previous discussions that the system I'm talking about is nowhere near the most space constrained of embedded systems under active development. So can we please stop this silly assumption that everyone has gigabytes to spare? :-) > > Yes of course, if the GDB project starts to operate on the basis that space is no object, I can and will fork. But isn't the whole point of open source projects that, while forking is of course allowed, it isn't something to be pushed as the best way to use the project? If forking was such a wonderful thing, we'd still have EGCS. > > paul > The flipside is that you're potentially making everybody else work harder for your sake. If you're the only one with a space-constrained target using stock gdbserver, then it might make more sense to look into tweaking a C++ gdbserver to stay under the size you require. For instance, when we discussed this before, 300K was OK for space, so presumably 600K is not good - perhaps just conditionalize the tracepoint bits to compensate for the space lost to C++ runtime? It's always seemed a little sloppy to me that we advertise gdbserver as suitable for targets, but don't actually track its size, consider each patch's effect, etc. For instance, a one-liner that brings in a bunch of library code might be more problematic for footprint than a page of new code. Stan stan@codesourcery.com ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-11-27 2:59 ` Stan Shebs @ 2012-11-27 15:17 ` Paul_Koning 2012-11-27 21:14 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Paul_Koning @ 2012-11-27 15:17 UTC (permalink / raw) To: stanshebs; +Cc: gdb On Nov 26, 2012, at 9:59 PM, Stan Shebs wrote: > ... > The flipside is that you're potentially making everybody else work harder for your sake. If you're the only one with a space-constrained target using stock gdbserver, then it might make more sense to look into tweaking a C++ gdbserver to stay under the size you require. For instance, when we discussed this before, 300K was OK for space, so presumably 600K is not good - perhaps just conditionalize the tracepoint bits to compensate for the space lost to C++ runtime? That's a fair point. If C++ makes gdbserver more maintainable or easier to improve, and those benefits outweigh the cost of dealing with space pressure for people who have it, that's a valid way to decide. Given how C++ is "designed" it's not necessarily obvious that switching to it is a good thing, never mind that it brings benefits that outweigh the size costs, but I'll concede the possibility. What concerned me was what seemed to be an assertion that space pressure doesn't exist. It does and it's real, but it is indeed one factor in a set of factors that need to be traded off. > > It's always seemed a little sloppy to me that we advertise gdbserver as suitable for targets, but don't actually track its size, consider each patch's effect, etc. For instance, a one-liner that brings in a bunch of library code might be more problematic for footprint than a page of new code. That's a very good point. paul ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-11-27 2:59 ` Stan Shebs 2012-11-27 15:17 ` Paul_Koning @ 2012-11-27 21:14 ` Tom Tromey 1 sibling, 0 replies; 116+ messages in thread From: Tom Tromey @ 2012-11-27 21:14 UTC (permalink / raw) To: Stan Shebs; +Cc: Paul_Koning, gdb >>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes: Stan> It's always seemed a little sloppy to me that we advertise gdbserver Stan> as suitable for targets, but don't actually track its size, consider Stan> each patch's effect, etc. For instance, a one-liner that brings in a Stan> bunch of library code might be more problematic for footprint than a Stan> page of new code. Yeah, this was my main takeaway from the last round of C++ discussions. If we are serious about gdbserver size, then we must set some constraints, and reject patches that violate these. However, I tend to think that either some interested party will have to design a compile-time-configuration approach for gdbserver, so that its size can be kept in check; or that we'll want to have two reference gdbservers, and let the current one grow feature-by-feature. There's always RDA: http://sourceware.org/rda/ Maybe there are others as well. Tom ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-04 20:48 ` Tom Tromey ` (2 preceding siblings ...) 2012-04-09 18:41 ` Pedro Alves @ 2012-04-09 23:23 ` Stan Shebs 2012-04-18 14:22 ` Pedro Alves 2012-04-19 8:43 ` Yao Qi 4 siblings, 1 reply; 116+ messages in thread From: Stan Shebs @ 2012-04-09 23:23 UTC (permalink / raw) To: gdb On 4/4/12 1:47 PM, Tom Tromey wrote: > > At the GCC Summit, I once again brought up the perennial idea of > moving GDB to be implemented in C++. There, we agreed that as a > follow-on to that discussion that I would raise the topic among the > GDB maintainers, and in particular present my migration plan. I support this plan. Many of the existing poor-cousin bits of infrastructure date back to a time when C++ was not a viable candidate for a widely-available tool, and others, more recent, are conscious imitations of C++ capabilities. At this point it starts to look a little perverse that we are doing a half-million-line program in C. The changes will be low-impact, perhaps even less visible than the K&R/ANSI C compatibility hacks that we maintained for so long. A secondary benefit will be that it opens up the use of minor C++ features, without getting us into the C90-vs-99 dilemma that has kept us from taking advantage of those. > > I don't believe we should convert all of GDB to C++. In particular I > think gdbserver should remain as pure C, and likewise any code shared > between gdbserver and gdb should be kept as such. I don't know that it matters that much for GDBserver anymore. When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today. Plus I note that GDBserver is picking up a load of functionality, and the truly space-conscious are better-advised to build a custom stub that is stripped down to just the bits they're going to use. Stan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-09 23:23 ` Stan Shebs @ 2012-04-18 14:22 ` Pedro Alves 2012-04-18 18:12 ` Stan Shebs 0 siblings, 1 reply; 116+ messages in thread From: Pedro Alves @ 2012-04-18 14:22 UTC (permalink / raw) To: Stan Shebs; +Cc: gdb On 04/10/2012 12:23 AM, Stan Shebs wrote: > On 4/4/12 1:47 PM, Tom Tromey wrote: >> I don't believe we should convert all of GDB to C++. In particular I >> think gdbserver should remain as pure C, and likewise any code shared >> between gdbserver and gdb should be kept as such. > > I don't know that it matters that much for GDBserver anymore. When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today. You're forgetting about all those uclibc (and musl's and other libc's of the world) targets that most probably don't even have a display, and some which don't support C++, and that still need to be debugged. A debugger agent is a system component that should aim lower than a bloated browser. Again, even the Android NDK doesn't support C++ exceptions properly (or maybe it does nowadays, but it didn't only a couple years ago), one of the biggest justifications for a C++ move. > Plus I note that GDBserver is picking up a load of functionality, and the truly space-conscious are better-advised to build a custom stub that is stripped down to just the bits they're going to use. If that's a concern, we can make the load of functionality build time optional. Heck, the Linux kernel can scale from tiny machines to the super computers of the world that way (and that no doubt contributes very much to its ever-growing ubiquitousness). I see no reason gdbserver can't. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 14:22 ` Pedro Alves @ 2012-04-18 18:12 ` Stan Shebs 2012-04-18 18:32 ` Paul_Koning 2012-04-18 18:37 ` Pedro Alves 0 siblings, 2 replies; 116+ messages in thread From: Stan Shebs @ 2012-04-18 18:12 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb On 4/18/12 7:21 AM, Pedro Alves wrote: > On 04/10/2012 12:23 AM, Stan Shebs wrote: > >> On 4/4/12 1:47 PM, Tom Tromey wrote: >>> I don't believe we should convert all of GDB to C++. In particular I >>> think gdbserver should remain as pure C, and likewise any code shared >>> between gdbserver and gdb should be kept as such. >> I don't know that it matters that much for GDBserver anymore. When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today. > > You're forgetting about all those uclibc (and musl's and other libc's of the world) targets > that most probably don't even have a display, and some which don't support C++, and that > still need to be debugged. A debugger agent is a system component that > should aim lower than a bloated browser. Again, even the Android NDK doesn't support > C++ exceptions properly (or maybe it does nowadays, but it didn't only a couple years ago), > one of the biggest justifications for a C++ move. > I've not forgotten them! :-) I just wonder what the size numbers are really like. We haven't really had to address GDBserver size before, not least because it wasn't getting much attention and people were OK with all kinds of functionality simply being left out. Paul Koning's bit about it being 300K is interesting, that's nearly an order of magnitude larger than I would have expected. But given the way our development timeframes operate, we might spend a lot of effort getting GDBserver down to 30K, only to find out it didn't really matter anymore because even GDB's smallest supported targets have 4G of RAM or more. Without a well-defined size target, and input from C++ mavens about minimum overheads, I don't think we can objectively say whether C++ is or is not acceptable for GDBserver. Stan ^ permalink raw reply [flat|nested] 116+ messages in thread
* RE: Will therefore GDB utilize C++ or not? 2012-04-18 18:12 ` Stan Shebs @ 2012-04-18 18:32 ` Paul_Koning 2012-04-18 18:37 ` Pedro Alves 1 sibling, 0 replies; 116+ messages in thread From: Paul_Koning @ 2012-04-18 18:32 UTC (permalink / raw) To: stanshebs, palves; +Cc: gdb -----Original Message----- From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Stan Shebs Sent: Wednesday, April 18, 2012 2:13 PM To: Pedro Alves Cc: gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? ... >Paul Koning's bit about it being 300K is interesting, that's nearly an order of magnitude larger than I would have expected. But given the way our development timeframes operate, we might spend a lot of effort getting GDBserver down to 30K, only to find out it didn't really matter anymore because even GDB's smallest supported targets have 4G of RAM or more. Note that I was describing a statically linked gdbserver. If I was willing to have it dynamically linked it would presumably be quite a lot smaller, but that means it won't help me debug problems involving library loading. paul ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-18 18:12 ` Stan Shebs 2012-04-18 18:32 ` Paul_Koning @ 2012-04-18 18:37 ` Pedro Alves 1 sibling, 0 replies; 116+ messages in thread From: Pedro Alves @ 2012-04-18 18:37 UTC (permalink / raw) To: Stan Shebs; +Cc: gdb On 04/18/2012 07:12 PM, Stan Shebs wrote: > On 4/18/12 7:21 AM, Pedro Alves wrote: >> On 04/10/2012 12:23 AM, Stan Shebs wrote: >> >>> On 4/4/12 1:47 PM, Tom Tromey wrote: >>>> I don't believe we should convert all of GDB to C++. In particular I >>>> think gdbserver should remain as pure C, and likewise any code shared >>>> between gdbserver and gdb should be kept as such. >>> I don't know that it matters that much for GDBserver anymore. When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today. >> >> You're forgetting about all those uclibc (and musl's and other libc's of the world) targets >> that most probably don't even have a display, and some which don't support C++, and that >> still need to be debugged. A debugger agent is a system component that >> should aim lower than a bloated browser. Again, even the Android NDK doesn't support >> C++ exceptions properly (or maybe it does nowadays, but it didn't only a couple years ago), >> one of the biggest justifications for a C++ move. >> > > I've not forgotten them! :-) I just wonder what the size numbers are really like. We haven't really had to address GDBserver size before, not least because it wasn't getting much attention and people were OK with all kinds of functionality simply being left out. > > Paul Koning's bit about it being 300K is interesting, that's nearly an order of magnitude larger than I would have expected. But given the way our development timeframes operate, we might spend a lot of effort getting GDBserver down to 30K, only to find out it didn't really matter anymore because even GDB's smallest supported targets have 4G of RAM or more. > > Without a well-defined size target, and input from C++ mavens about minimum overheads, I don't think we can objectively say whether C++ is or is not acceptable for GDBserver. > There was also the "share code with the IPA" argument. I don't think making the IPA a C++ library is a good idea. -- Pedro Alves ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-04 20:48 ` Tom Tromey ` (3 preceding siblings ...) 2012-04-09 23:23 ` Stan Shebs @ 2012-04-19 8:43 ` Yao Qi 2012-12-04 14:17 ` Jan Kratochvil 4 siblings, 1 reply; 116+ messages in thread From: Yao Qi @ 2012-04-19 8:43 UTC (permalink / raw) To: Tom Tromey; +Cc: Jan Kratochvil, gdb On 04/05/2012 04:47 AM, Tom Tromey wrote: > My concrete transition proposal is: > I went through discussions in this thread, and go back to read Tom's proposal again. Get some additional thoughts, maybe, we can start from something easy and less-controvesy, > 1. Modify GDB so it can be compiled with -Wc++-compat. > This would be the first patch series. There is already an archer > branch for this. > Modify GDB as well as GDBserver/IPA so they can be compiled with -Wc++-compat. > 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is > not complete). This would be the second patch series. > Change to use C++ compiler to compile GDB, GDBserver and IPA. If this is too aggressive, we can use C++ compiler to compile GDB and keep C compiler to compiler GDBserver and IPA. Sources in gdb/common/ will be compiled by C compiler and C++ compiler respectively. Is it possible? > 3. Require C++. Then, we can require C++ for GDB and keep GDBserver and IPA unchanged. > > 4. Change selected modules to use C++ rather than C. > I don't think a wholesale change makes sense, but some areas would > benefit. > > My first target would be to change the exception handling system to > use C++ exceptions. This would enable us to begin using RAII in > some areas, which would help robustness. > > My concrete plan here is: > > * Use the GCC cleanup-checking plugin I already wrote to detect > cleanup-aware functions. > > * Modify these functions, using a script, to add an RAII-using > object to manage the local cleanups. This is important so that > we run cleanups at the correct time during stack unwinding. > > * Change throw_exception to use 'throw' and all TRY_EXCEPT > instances to try...catch. > > * Finally, convert functions to static RAII usage when appropriate; > this will be an ongoing transition. Most of the objections are to these points. We can postpone them, and .... > > I think our second target will be sorting out Python reference > counting, so we can avoid the many problems we have had there. ... start this first, if this is quite isolated and not dependent on #4 above. Python reference counting will not be used in GDBserver, so we don't have to worry about GDB/GDBserver code sharing. -- Yao (é½å°§) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-04-19 8:43 ` Yao Qi @ 2012-12-04 14:17 ` Jan Kratochvil 2012-12-04 14:44 ` Mark Kettenis 0 siblings, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-12-04 14:17 UTC (permalink / raw) To: gdb; +Cc: Tom Tromey, Matt Rice, Yao Qi On Thu, 19 Apr 2012 10:43:51 +0200, Yao Qi wrote: [...] > maybe, we can start from something easy and less-controvesy, > > On 04/05/2012 04:47 AM, Tom Tromey wrote: > > 1. Modify GDB so it can be compiled with -Wc++-compat. > > This would be the first patch series. There is already an archer > > branch for this. > > Modify GDB as well as GDBserver/IPA so they can be compiled with > -Wc++-compat. > > > 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is > > not complete). This would be the second patch series. > > > > Change to use C++ compiler to compile GDB, GDBserver and IPA. If this > is too aggressive, we can use C++ compiler to compile GDB and keep C > compiler to compiler GDBserver and IPA. Sources in gdb/common/ will be > compiled by C compiler and C++ compiler respectively. Is it possible? For one of the justifications of C++ http://sourceware.org/ml/gdb/2012-11/msg00070.html speficially to upstream the 64-bit inferior offsets/sizes as present in many patches posted by Siddhesh Poyarekar <siddhesh@redhat.com>: It would be enough to have GDB (neither gdbserver nor IPA) compilable as C++. Explicit configure option would be required. It would be used to create the 64-bit offsets patch and then also during nightly regression testing to catch possible following 64-bit offsets type violations/regressions. Is it enough plan to justify the -Wc++-compat compatibility step? That is to update and check-in archer-ratmice-compile-Wc++-compat. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-04 14:17 ` Jan Kratochvil @ 2012-12-04 14:44 ` Mark Kettenis 2012-12-04 14:52 ` Jan Kratochvil 0 siblings, 1 reply; 116+ messages in thread From: Mark Kettenis @ 2012-12-04 14:44 UTC (permalink / raw) To: jan.kratochvil; +Cc: gdb, tromey, ratmice, yao > Date: Tue, 4 Dec 2012 15:17:08 +0100 > From: Jan Kratochvil <jan.kratochvil@redhat.com> > > On Thu, 19 Apr 2012 10:43:51 +0200, Yao Qi wrote: > [...] > > maybe, we can start from something easy and less-controvesy, > > > > On 04/05/2012 04:47 AM, Tom Tromey wrote: > > > 1. Modify GDB so it can be compiled with -Wc++-compat. > > > This would be the first patch series. There is already an archer > > > branch for this. > > > > Modify GDB as well as GDBserver/IPA so they can be compiled with > > -Wc++-compat. > > > > > 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is > > > not complete). This would be the second patch series. > > > > > > > Change to use C++ compiler to compile GDB, GDBserver and IPA. If this > > is too aggressive, we can use C++ compiler to compile GDB and keep C > > compiler to compiler GDBserver and IPA. Sources in gdb/common/ will be > > compiled by C compiler and C++ compiler respectively. Is it possible? > > For one of the justifications of C++ > http://sourceware.org/ml/gdb/2012-11/msg00070.html > speficially to upstream the 64-bit inferior offsets/sizes as present in many > patches posted by Siddhesh Poyarekar <siddhesh@redhat.com>: > > It would be enough to have GDB (neither gdbserver nor IPA) compilable as C++. > Explicit configure option would be required. It would be used to create the > 64-bit offsets patch and then also during nightly regression testing to catch > possible following 64-bit offsets type violations/regressions. > > > Is it enough plan to justify the -Wc++-compat compatibility step? > That is to update and check-in archer-ratmice-compile-Wc++-compat. Not without proper review of the changes. And since my position on C++ has changed, I'd not really eager to do that. But if -Wc++-compat would make you happy, and stop pushing for switching GDB to C++, I'd be willing to spend some time to help. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-04 14:44 ` Mark Kettenis @ 2012-12-04 14:52 ` Jan Kratochvil 2012-12-06 20:39 ` Matt Rice 0 siblings, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-12-04 14:52 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb, tromey, ratmice, yao On Tue, 04 Dec 2012 15:44:16 +0100, Mark Kettenis wrote: > > Is it enough plan to justify the -Wc++-compat compatibility step? > > That is to update and check-in archer-ratmice-compile-Wc++-compat. > > Not without proper review of the changes. And since my position on > C++ has changed, I'd not really eager to do that. But if -Wc++-compat > would make you happy, and stop pushing for switching GDB to C++, No matter whether C++ will happen or not -Wc++-compat is already useful (for the 64-bit offsets upstreaming). This is why I ask for it on its own. While -Wc++-compat enables fixing the 64-bit offsets in GDB it is only like 1% (random guess) of GDB bugs fixes C++ enables us to do. So the decision of -Wc++-compat is orthogonal to the C++ decision. > I'd be willing to spend some time to help. There is hopefully not much help needed, Matt Rice was offering to update archer-ratmice-compile-Wc++-compat, and I think one can safely verify the patch is valid (besides some eyes review) also by comparing byte-by-byte the compiled stripped binaries. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-04 14:52 ` Jan Kratochvil @ 2012-12-06 20:39 ` Matt Rice 2012-12-07 12:57 ` Jan Kratochvil 2012-12-07 13:25 ` Yao Qi 0 siblings, 2 replies; 116+ messages in thread From: Matt Rice @ 2012-12-06 20:39 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Mark Kettenis, gdb, tromey, yao On Tue, Dec 4, 2012 at 6:51 AM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote: > On Tue, 04 Dec 2012 15:44:16 +0100, Mark Kettenis wrote: >> > Is it enough plan to justify the -Wc++-compat compatibility step? >> > That is to update and check-in archer-ratmice-compile-Wc++-compat. >> >> Not without proper review of the changes. And since my position on >> C++ has changed, I'd not really eager to do that. But if -Wc++-compat >> would make you happy, and stop pushing for switching GDB to C++, > > No matter whether C++ will happen or not -Wc++-compat is already useful > (for the 64-bit offsets upstreaming). This is why I ask for it on its own. > > While -Wc++-compat enables fixing the 64-bit offsets in GDB it is only like > 1% (random guess) of GDB bugs fixes C++ enables us to do. So the decision of > -Wc++-compat is orthogonal to the C++ decision. > > >> I'd be willing to spend some time to help. > > There is hopefully not much help needed, Matt Rice was offering to update > archer-ratmice-compile-Wc++-compat, and I think one can safely verify the > patch is valid (besides some eyes review) also by comparing byte-by-byte the > compiled stripped binaries. > k, will go ahead and get started on this i've always felt we should at least do -Wc++-compat since when doing the patch originally it did make apparent at least one bug in gdb. If anyone has any particularly large change to an existing source file, and they'd prefer I postpone work on that file until later please let me know, it might save work for one of us or the other. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-06 20:39 ` Matt Rice @ 2012-12-07 12:57 ` Jan Kratochvil 2012-12-07 13:25 ` Yao Qi 1 sibling, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-12-07 12:57 UTC (permalink / raw) To: Matt Rice; +Cc: Mark Kettenis, gdb, tromey, yao On Thu, 06 Dec 2012 21:39:27 +0100, Matt Rice wrote: > k, will go ahead and get started on this i've always felt we should at > least do -Wc++-compat That would be great, thanks. In fact I do not see any possible technical reason against -Wc++-compat, it has no disadvantages (just possibly "needless" many mechanical changes of your patch). Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-06 20:39 ` Matt Rice 2012-12-07 12:57 ` Jan Kratochvil @ 2012-12-07 13:25 ` Yao Qi 2012-12-11 6:25 ` Matt Rice 1 sibling, 1 reply; 116+ messages in thread From: Yao Qi @ 2012-12-07 13:25 UTC (permalink / raw) To: Matt Rice; +Cc: Jan Kratochvil, Mark Kettenis, gdb, tromey On 12/07/2012 04:39 AM, Matt Rice wrote: > If anyone has any particularly large change to an existing source > file, and they'd prefer I postpone work on that file until later > please let me know, it might save work for one of us or the other. I have a not-small patch series 'rsp async notification' being reviewed recently and hopefully give new version V4 next Monday. I don't want to postpone your work. How do you change the source tree? Are you going to post patches one by one to fix compilation errors, and finally turn -Wc++-compat on in the last step? -- Yao (é½å°§) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-07 13:25 ` Yao Qi @ 2012-12-11 6:25 ` Matt Rice 2012-12-13 15:12 ` Jan Kratochvil 0 siblings, 1 reply; 116+ messages in thread From: Matt Rice @ 2012-12-11 6:25 UTC (permalink / raw) To: Yao Qi; +Cc: Jan Kratochvil, Mark Kettenis, gdb, tromey On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> wrote: > On 12/07/2012 04:39 AM, Matt Rice wrote: >> >> If anyone has any particularly large change to an existing source >> file, and they'd prefer I postpone work on that file until later >> please let me know, it might save work for one of us or the other. > > > I have a not-small patch series 'rsp async notification' being reviewed > recently and hopefully give new version V4 next Monday. I don't want to > postpone your work. k > How do you change the source tree? I create a git branch for each type of error message which gets rebased, write some scripts to create a merge branch to test compilation and run testsuite, and a branch where self-conflicts go which contains the lines which are covered by more than one error type. this allows me a certain amount of flexibility as to how patches are posted I can either do a series on a specific file/glob e.g. post [1/?? mi/* error message 'foo'] [2/?? mi/* error message 'bar'] or a series error message 'foo' followed by a series for error message 'bar', this I think is easier for mass review, while the other maybe better if each maintainer prefers to share the burden of review. as far as the method, I'm doing a simple/stupid pass of 'fix the error message robotically', introducing nothing new I don't have to, there will be obvious cases of eyesores, where we may want to introduce new types for example. we can consider this pass in bringing those to light, and getting the other obvious changes out of the way. It will probably be easier for me to just cherry-pick these later, than to keep them on their own branch. > Are you going to > post patches one by one to fix compilation errors, and finally turn > -Wc++-compat on in the last step? yes but I think that there should be a grace period in between commiting the final patch to fix compilation errors, and comitting the patch to turn -Wc++-compat on in order to allow target maintainers to test *-tdep.c and any macro guarded code which may not be covered by --enable-targets=all on a platform which I do not have access to. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-11 6:25 ` Matt Rice @ 2012-12-13 15:12 ` Jan Kratochvil 2012-12-14 11:03 ` Matt Rice 0 siblings, 1 reply; 116+ messages in thread From: Jan Kratochvil @ 2012-12-13 15:12 UTC (permalink / raw) To: Matt Rice; +Cc: Yao Qi, Mark Kettenis, gdb, tromey On Tue, 11 Dec 2012 07:25:33 +0100, Matt Rice wrote: > On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> wrote: > > How do you change the source tree? > > I create a git branch for each type of error message which gets > rebased, could you provide some small preview of the work? I would like to prevent the case of 64-bit offsets were weeks/months of work were invested to find in the end it is not well reviewable==usable. On archer-ratmice-compile-Wc++-compat where the current trunk is b68c4be8e0c1236639c6e5fc98c6894a746dde4e (from 2010) I have found the last FSF GDB merge was from e884cc5b62f170280dd49a35793bb516d95e7d8d and while trying to /usr/bin/cmp a stripped binary (which does not match) I have found this change: -void * -grow_vect (void *vect, size_t *size, size_t min_size, int element_size) +void +grow_vect (gdb_byte **vect, size_t *size, size_t min_size, int element_size) [...] - vect = xrealloc (vect, *size * element_size); + *vect = (gdb_byte *) xrealloc (*vect, *size * element_size); } - return vect; } which while (probably) correct I find it outside of the scope of this branch, making it more difficult to verify. BTW I was using ad hoc objdump -d --no-show-raw-insn gdb >1 objdump -d --no-show-raw-insn gdb >2 /usr/bin/diff -u [12] | vim - and there /^ .*\n .*\n .*\n .*\n .*\n .*\n to find: 72e351: mov -0x8(%rbp),%rax - 72e355: mov (%rax),%rax - 72e358: mov %rdx,%rsi - 72e35b: mov %rax,%rdi - 72e35e: callq 48ead0 <xrealloc> + 72e355: mov %rdx,%rsi + 72e358: mov %rax,%rdi + 72e35b: callq 48ead0 <xrealloc> Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-13 15:12 ` Jan Kratochvil @ 2012-12-14 11:03 ` Matt Rice 2012-12-14 12:16 ` Jan Kratochvil 0 siblings, 1 reply; 116+ messages in thread From: Matt Rice @ 2012-12-14 11:03 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Yao Qi, Mark Kettenis, gdb, tromey On Thu, Dec 13, 2012 at 7:12 AM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote: > On Tue, 11 Dec 2012 07:25:33 +0100, Matt Rice wrote: >> On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> wrote: >> > How do you change the source tree? >> >> I create a git branch for each type of error message which gets >> rebased, > > could you provide some small preview of the work? > > I would like to prevent the case of 64-bit offsets were weeks/months of work > were invested to find in the end it is not well reviewable==usable. unfortunately I'm still trying to muster up motivation for this, I'll post a repository on gitorious when I do manage to get started since I don't want to litter the archer repo with a ton of branches. > On archer-ratmice-compile-Wc++-compat where the current trunk is > b68c4be8e0c1236639c6e5fc98c6894a746dde4e (from 2010) > I have found the last FSF GDB merge was from > e884cc5b62f170280dd49a35793bb516d95e7d8d > and while trying to /usr/bin/cmp a stripped binary (which does not match) > I have found this change: > > -void * > -grow_vect (void *vect, size_t *size, size_t min_size, int element_size) > +void > +grow_vect (gdb_byte **vect, size_t *size, size_t min_size, int element_size) > [...] > - vect = xrealloc (vect, *size * element_size); > + *vect = (gdb_byte *) xrealloc (*vect, *size * element_size); > } > - return vect; > } > > which while (probably) correct I find it outside of the scope of this branch, > making it more difficult to verify. This patch came from Joel Brobecker, after discussions on IRC about the GROW_VECT macro of ada-lang.h where we needed to add a cast to the (v) = grow_vect() call in the macro like: (v) (cast) = grow_vect(...). I believe my initial patch which I still have around added a cast argument to the macro (which requires updating all callers) similarly since we're now hard coding gdb_byte in the macro, we could also just hard code the cast in the macro without updating the grow_vect function, also forging updating callers (I don't believe it was called with anything but gdb_byte's in the first place). this really was the only place that had changes going beyond mundane. and since ada is his territory I just went with his patch, though I somewhat prefer adding the cast argument to the macro/updating callers as it keeps hard coded types out of otherwise generic code. I'd rather not do that if it means someone later wants to go back and deupdate all of the macro callers. > BTW I was using ad hoc > objdump -d --no-show-raw-insn gdb >1 > objdump -d --no-show-raw-insn gdb >2 > /usr/bin/diff -u [12] | vim - > and there > /^ .*\n .*\n .*\n .*\n .*\n .*\n > to find: > 72e351: mov -0x8(%rbp),%rax > - 72e355: mov (%rax),%rax > - 72e358: mov %rdx,%rsi > - 72e35b: mov %rax,%rdi > - 72e35e: callq 48ead0 <xrealloc> > + 72e355: mov %rdx,%rsi > + 72e358: mov %rax,%rdi > + 72e35b: callq 48ead0 <xrealloc> good to see that this picked up the change, and more importantly no others. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Will therefore GDB utilize C++ or not? 2012-12-14 11:03 ` Matt Rice @ 2012-12-14 12:16 ` Jan Kratochvil 0 siblings, 0 replies; 116+ messages in thread From: Jan Kratochvil @ 2012-12-14 12:16 UTC (permalink / raw) To: Matt Rice; +Cc: Yao Qi, Mark Kettenis, gdb, tromey On Fri, 14 Dec 2012 12:03:24 +0100, Matt Rice wrote: > unfortunately I'm still trying to muster up motivation for this, Please tell if you somehow suspend / stop the work. I have now the fun of 377kB bitpos patch to maintain off-trunk until -Wc++-compat gets done. So I have more than enough motivation for -Wc++-compat. > I'll post a repository on gitorious when I do manage to get started > since I don't want to litter the archer repo with a ton of branches. I find myself sourceware archer.git a perfect place for it; in fact it has very many dead branches, it is only important to track the live ones at http://sourceware.org/gdb/wiki/ArcherBranchManagement > this really was the only place that had changes going beyond mundane. > and since ada is his territory I just went with his patch, Such patches may be fine but please keep them on a separate add-on branch to make the review of the main -Wc++-compat patch easy/possible. > I'd rather not do that if it means someone later wants to go back and > deupdate all of the macro callers. From my point of view one should just keep the current macro magic as is. As - clarifying as unrelated to -Wc++-compat - hopefully in the future GDB may switch to C++ and it all can be / gets normally (re)implemented in C++ there. Thanks, Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
end of thread, other threads:[~2012-12-14 12:16 UTC | newest] Thread overview: 116+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-30 16:14 Will therefore GDB utilize C++ or not? Jan Kratochvil 2012-04-04 20:48 ` Tom Tromey 2012-04-04 21:55 ` Mark Kettenis 2012-04-05 3:31 ` Sergio Durigan Junior 2012-04-05 11:46 ` Phil Muldoon 2012-04-06 0:35 ` Will therefore GDB utilize C++? Not John Gilmore 2012-04-06 1:35 ` Russell Shaw 2012-04-06 13:16 ` Joel Brobecker 2012-04-06 14:43 ` Russell Shaw 2012-04-06 15:34 ` Michael Eager 2012-04-06 23:32 ` John Gilmore 2012-04-07 1:04 ` Robert Dewar 2012-04-07 1:52 ` Thomas Dineen 2012-04-07 16:54 ` Michael Eager 2012-04-09 23:59 ` Stan Shebs 2012-04-05 0:22 ` Will therefore GDB utilize C++ or not? asmwarrior 2012-04-09 18:41 ` Pedro Alves 2012-04-09 19:05 ` Jan Kratochvil 2012-04-09 19:49 ` Pedro Alves 2012-04-09 20:15 ` Paul Smith 2012-04-12 20:06 ` Daniel Jacobowitz 2012-04-12 21:28 ` Paul_Koning 2012-04-13 0:04 ` Doug Evans 2012-04-18 14:10 ` Pedro Alves 2012-04-18 20:27 ` Tom Tromey 2012-04-18 14:08 ` Pedro Alves 2012-04-21 17:24 ` Daniel Jacobowitz 2012-04-16 6:55 ` Jan Kratochvil 2012-04-18 14:11 ` Pedro Alves 2012-04-18 15:16 ` Jan Kratochvil 2012-04-18 15:28 ` Pedro Alves 2012-04-18 15:54 ` Jan Kratochvil 2012-04-18 16:01 ` Pedro Alves 2012-04-18 16:07 ` Joel Brobecker 2012-04-18 16:13 ` Jan Kratochvil 2012-04-18 16:23 ` Joel Brobecker 2012-04-18 16:31 ` Joel Sherrill 2012-04-18 16:50 ` Pedro Alves 2012-04-18 16:57 ` Joel Brobecker 2012-04-18 17:28 ` Joel Sherrill 2012-04-18 17:40 ` Paul_Koning 2012-04-18 20:37 ` Frank Ch. Eigler 2012-04-18 20:38 ` Paul_Koning 2012-04-18 20:36 ` Tom Tromey 2012-04-18 17:48 ` John Gilmore 2012-04-18 19:07 ` Tom Tromey 2012-04-18 23:10 ` John Gilmore 2012-05-18 18:36 ` Tom Tromey 2012-05-18 18:47 ` Paul_Koning 2012-05-18 19:36 ` Tom Tromey 2012-05-18 19:44 ` Paul_Koning 2012-05-18 20:07 ` Tom Tromey 2012-05-18 20:41 ` Aurelian Melinte 2012-05-18 18:51 ` Lazy CU expansion (Was: Will therefore GDB utilize C++ or not?) Tom Tromey 2012-04-18 20:34 ` Will therefore GDB utilize C++ or not? Tom Tromey 2012-04-18 19:18 ` Will C++ proponents spend 20 minutes to try what they're proposing? John Gilmore 2012-04-18 19:23 ` Jan Kratochvil 2012-04-18 20:40 ` Tom Tromey 2012-04-18 20:56 ` Mike Frysinger 2012-04-18 20:31 ` Will therefore GDB utilize C++ or not? Tom Tromey 2012-04-18 20:25 ` Tom Tromey 2012-05-21 18:11 ` Pedro Alves 2012-05-21 18:36 ` Jan Kratochvil 2012-11-21 20:18 ` Jan Kratochvil 2012-04-10 0:23 ` Yao Qi 2012-04-10 9:47 ` Yao Qi 2012-04-18 20:11 ` Tom Tromey 2012-04-18 20:31 ` Can it really be ok to map GPL'd code into any old process? John Gilmore 2012-04-18 20:36 ` Pedro Alves 2012-04-23 18:03 ` Will therefore GDB utilize C++ or not? Tom Tromey 2012-05-18 19:55 ` Tom Tromey 2012-05-18 21:56 ` Joel Brobecker 2012-05-19 2:17 ` Tom Tromey 2012-05-19 15:21 ` Daniel Jacobowitz 2012-05-19 21:36 ` Joel Brobecker 2012-05-20 12:16 ` Frank Ch. Eigler 2012-05-21 15:56 ` Pedro Alves 2012-05-21 16:15 ` Jan Kratochvil 2012-05-21 17:37 ` Paul_Koning 2012-05-21 17:58 ` Jan Kratochvil 2012-05-22 18:03 ` Paul_Koning 2012-05-21 18:08 ` Pedro Alves 2012-05-21 18:08 ` Tom Tromey 2012-05-21 18:10 ` Jan Kratochvil 2012-05-21 18:54 ` Matt Rice 2012-05-26 15:50 ` Jan Kratochvil 2012-06-02 7:01 ` Russell Shaw 2012-06-02 7:13 ` Jan Kratochvil 2012-06-02 10:47 ` Russell Shaw 2012-06-02 11:10 ` Jan Kratochvil 2012-06-02 11:15 ` Russell Shaw 2012-06-02 11:15 ` Jan Kratochvil 2012-11-22 18:46 ` Jan Kratochvil 2012-11-22 21:42 ` John Gilmore 2012-11-23 15:26 ` Jan Kratochvil 2012-11-27 1:29 ` Stan Shebs 2012-11-27 2:02 ` Paul_Koning 2012-11-27 2:59 ` Stan Shebs 2012-11-27 15:17 ` Paul_Koning 2012-11-27 21:14 ` Tom Tromey 2012-04-09 23:23 ` Stan Shebs 2012-04-18 14:22 ` Pedro Alves 2012-04-18 18:12 ` Stan Shebs 2012-04-18 18:32 ` Paul_Koning 2012-04-18 18:37 ` Pedro Alves 2012-04-19 8:43 ` Yao Qi 2012-12-04 14:17 ` Jan Kratochvil 2012-12-04 14:44 ` Mark Kettenis 2012-12-04 14:52 ` Jan Kratochvil 2012-12-06 20:39 ` Matt Rice 2012-12-07 12:57 ` Jan Kratochvil 2012-12-07 13:25 ` Yao Qi 2012-12-11 6:25 ` Matt Rice 2012-12-13 15:12 ` Jan Kratochvil 2012-12-14 11:03 ` Matt Rice 2012-12-14 12:16 ` Jan Kratochvil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).