[C++] System Requirements

[C++] System Requirements

[Ben Longbons]

Under the assumption that most active gdb maintainers intend that
future gdb releases be written in C++, I am presenting a possible plan
for the conversion, based on my experience with a conversion about
1/5th the size of gdb.

I have found 3.5 areas of discussion, 2.5 of which I have actually written.
- System Requirements
- Attack Plan
-- Warning Header Proposal
- Style Guide (to be written, probably not by me)

A shared editing pad is available at http://piratepad.net/gdb-cxx, it
will contain links to the archived mails so don't be concerned about
editing what I wrote there.

This thread will discuss system requirements.

This is going to turn into a flamefest, but at the very minimum we
*must* agree that choosing the system requirements is a trade-off
between how many systems meet the requirements and how much effort it
takes to do anything under those requirements. I do not ask for higher
minimum requirements for no reason! Not all Turing machines are equal,
even if in theory they can solve each other's problems.

We have already seen the kind of trouble it takes to support old
systems with Python 2.4 and also new systems with Python3. This would
be much easier if the old systems requirement was Python 2.6, which
can safely be coinstalled. I am glad that gdb's python support is not
my problem.

Unlike python, it is intrusive to upgrade the system gcc, since every
application links to it.

I consider that there are two different sets of requirements:
- The stricter requirements for a system that active gdb developers
have access to ("development mode requirements")
- The looser requirements for a system to deploy ("deploy mode requirements").

As long as we regularly test the "deploy mode", it is reasonable to
have different settings used if you meet the development requirements.
Additionally, it is not absolutely necessary to meet the "developer
mode" to develop gdb.

I propose that the minimum "development requirements" is either gcc
4.6 or 4.7. The rest of this section discusses the deploy
requirements.

What are the current minimum deploy requirements (for gdb 7.6)?
What were the minimum deploy requirements about 5 years ago (for gdb 7.0 or so)?
What were the minimum deploy requirements about 10 years ago (for gdb
6.0 or so)?
What were the minimum deploy requirements about 15 years ago (for gdb
4.18 or so)?

gcc 3.3 is the oldest I've heard anyone tries to support. It is used
by NetBSD 5.1 (2010-11-19)
gcc 3.4 was the last deliberate incompatible ABI change (libstdc++.so.6).
gcc 4.0 is used by older Apple systems
gcc 4.1 is used by RHEL 5
gcc 4.2 is the latest gcc shipped by Apple and OpenBSD because of the
GPL3 thing. However, this is becoming less important now that clang
exists (but I do not think clang will necessarily support the
"development requirements"). And do you *really* want free software to
be help hostage by Apple?

gcc 4.3 is the first release that supports some form of C++11. It is
also the oldest version of gcc that I can actually get to build on my
system.
C++11 is a *huge* mindset change for writing C++ - it's practically a
new language, when taken all together. gcc 4.3 does not support very
much of C++11, but it does support some core things:
- rvalue references (these are huge, both for idiom and performance)
- static_assert
- decltype (not quite the same as gcc's typeof extension)

gcc 4.4 supports more of C++11. It is the compiler shipped with RHEL6
and Debian 6
- initializer lists (much less typing)
- auto
- enum class (much more safety for new code)
- = default and = delete
I recommend gcc 4.4 as the minimum deploy requirements. If people
expect to use the latest and greatest version of gdb, they should be
willing to provided a somewhat recent standards-compliant compiler.
This gcc version is very widely deployed, so relatively few people
will be forced to use an older version of gdb if this is chosen.
If it would make the maintenance burdern lighter, it *would* be
possible to declare 4.2 as the minimum requirement for the initial
conversion and upgrade the requirements for the next release. However,
I do not recommend this unless absolutely needed, and WE MUST NOT
SUPPORT GCC 4.2 INDEFINITELY. If you disagree with my recommendation
for now, what is your plain for dropping gcc 4.2?
At some point, gcc 4.4 will go the way of gcc 4.2, and the requirement
can be raised again.
How will this be defined?

I will continue listing the advantages of each newer version

gcc 4.5 doesn't much to say about it, and I'm not aware of any major
deployments. It does have some less-frequently-used features:
- lambda functions
- explicit conversion operators
- local types as template arguments

gcc 4.6 is the next major step towards C++11 compliance, but since
it's getting closer, I keep seeing its shortcomings. But its benefits
are:
- nullptr (there exist compatibility libraries for this)
- forward declarations of enums (unfortunately these are still buggy
with debuginfo even with the most recent gcc, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 )
- constexpr (this is huge)
- range-based for (much less typing; not really compatible with
various macros that emulated this)
- unrestricted unions (not used often, but when you need them, they're
hard to do without)
GCC 4.6 is also the first release that supports #pragma GCC diagnostic
inside a function, which is absolutely essential in my "attack plan"
and can (using _Pragma form) be #define'd out in deployment mode.

gcc 4.7 is the first release that is practically compliant. Note,
however, that gcc 4.7.0 and gcc 4.7.1 must be avoided at all costs due
to an ABI compatibility; gcc 4.7.2 is the requirement in this case
(I'm not sure which point versions are okay for the other versions).
- in-class non-static data initializers
- override and final (can be #define'd out for deployment and used in
development)
- template aliases (these are *incredibly* useful, and among many
other benefits can make debugging sane since gdb doesn't support
operator overloading in the print command yet)
- delegating constructors
- user-defined literals (useful for string-safety)

gcc 4.8.1 is the first fully-compliant C++11 release. At this point,
you only have to worry about bugs and DRs (I recently had some code
that was illegal according to c++11 as written, but legal according to
a DR).
- move this (can be #define'd out for deployment)
- inheriting constructors

The features I listed above are the ones I use regularly in my own
codebase. For a more complete list, see:
http://gcc.gnu.org/projects/cxx0x.html

Thanks for your time,
Ben Longbons (o11c on IRC)

Re: [C++] System Requirements

[Ben Longbons]

On Fri, Dec 13, 2013 at 4:34 PM, Ben Longbons <brlongbons@gmail.com> wrote:
> <snip>

Table of selected distributions and their compiler versions.
RHEL 7 (? .. ?): gcc 4.8.2
RHEL 6 (2010-11-10 .. ????): gcc 4.4.7
RHEL 5 (2007-03-15 .. ????): gcc 4.1.2
(I am unsure of exactly which of Red Hat's support levels is most
meaningful, I imagine RHEL5 to be the point of contention)

Debian 7 (2013-05-04 .. ??): gcc 4.7.2
Debian 6 (2011-02-06 .. ?2014-05): gcc 4.4.5
Debian 5 (2009-02-15 .. 2012-02-06): gcc 4.3.2

Ubuntu 14.04 (?2014-04-17 .. ?2019-04): gcc 4.8.2
Ubuntu 12.04 (2012-04-26 .. 2017-04): gcc 4.6.3
Ubuntu 10.04 (2010-04-29 .. ?2015-04): gcc 4.4.3
Ubuntu 8.04 (2008-04-24 .. 2013-05-09): gcc 4.2.3

FreeBSD 10 (?): gcc 4.6.4
FreeBSD 9.2 (2013-09-30): gcc 4.6.4
FreeBSD 9.0 (2012-01-12): gcc 4.4.7
FreeBSD 8.2 (2011-02-23): gcc 4.3.4

NetBSD 6.1.1 (2013-08-22): gcc 4.8.1
NetBSD 5.1 (2010-11-19): gcc 3.3.6

OpenBSD 5.4 (2013-11-01): gcc 4.2.1
OpenBSD 4.7 (2010-05-19): gcc 3.3.5

Mac OS X 10.8 (2012-07-25) (Xcode 5): force clang snapshot
Mac OS X 10.6 (2009-06-08) (Xcode 3.2): clang snapshots available
Mac OS X 10.5 (2007-10-26) (Xcode 3.1): gcc 4.2
Mac OS X 10.4 (2005-04-29) (Xcode 2.0): gcc 4.0

Re: [C++] System Requirements

[Michael Veksler]

On 14/12/13 02:40, Ben Longbons wrote:
> <snip>
> NetBSD 6.1.1 (2013-08-22): gcc 4.8.1
> NetBSD 5.1 (2010-11-19): gcc 3.3.6
>
> OpenBSD 5.4 (2013-11-01): gcc 4.2.1
> OpenBSD 4.7 (2010-05-19): gcc 3.3.5
>
>
I recommend to avoid gcc versions prior to gcc-3.4. Over a decade ago I 
had to port code from gcc-3.2 to gcc-3.4
without losing support for gcc-3.2. Even though the code was much 
smaller than gdb it was a pain to support
both versions in parallel:
1. gcc-3.2 has an old C++ parser and supports a dialect of C++ which 
predates ISO C++.
2. gcc-3.2 does not have namespace
3. Requires STL as a separate library
4. Containers of the STL libraries do not understand allocators, and 
can't be taught to due to limitations in old C++
5. Templates have significantly different semantics, and define a 
one-pass parsing (unlike 2 pass in ISO C++).

Avoid gcc-3.2

Michael

Re: [C++] System Requirements

[Jan Kratochvil]

On Sat, 14 Dec 2013 01:34:17 +0100, Ben Longbons wrote:
> We have already seen the kind of trouble it takes to support old
> systems with Python 2.4

Python 2.4 has been recently decided to be discontinued:
	https://sourceware.org/ml/gdb-patches/2013-12/msg00402.html


> I propose that the minimum "development requirements" is either gcc
> 4.6 or 4.7.

I find it too strict for GDB even myself, for example RHEL-5 with gcc-4.1
still should be able to build upstream GDB even in some restricted form (such
as without the Python mentioned above).

There are enough benefits even just with C++03.  C++11 etc. extensions still
can be done incrementally in the future.

There should be first reviewed+accepted patchset, already posted at
	[PATCH 00/18] -Wc++-compat patches v2.0
	https://sourceware.org/ml/gdb-patches/2013-10/msg00641.html
plus then sure many other patches you also suggest in the other mails.


Regards,
Jan

Re: [C++] System Requirements

[Ben Longbons]

On Sun, Dec 15, 2013 at 7:31 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 14 Dec 2013 01:34:17 +0100, Ben Longbons wrote:
>> We have already seen the kind of trouble it takes to support old
>> systems with Python 2.4
>
> Python 2.4 has been recently decided to be discontinued:
>         https://sourceware.org/ml/gdb-patches/2013-12/msg00402.html
Ah, good to hear! But even though it's an optional feature, it
highlights the kind of problem we face with older dependency versions.

>> I propose that the minimum "development requirements" is either gcc
>> 4.6 or 4.7.
>
> I find it too strict for GDB even myself, for example RHEL-5 with gcc-4.1
> still should be able to build upstream GDB even in some restricted form (such
> as without the Python mentioned above).
"some restricted form" would be what I call "deploy requirements", and
would be enough to enable all user-visible features. The "develop
requirements" would only be what's necessary to enable all the
compiler warnings, ensure easy debugging, etc.

Personally, I don't get why people who are using long-term "stable"
releases expect to be able to use the latest and greatest version of
anything. If you only need to *use* gdb, you can just stick to older
versions (including 7.7) which are still fully-featured releases.

But you're saying you're using RHEL5 for your *development* ? I'm not
used to developers who can even stand not using the latest release.

To quote one of my covolunteers, who uses frankendebian: "I think the
main reason I run a lot of testing packages is I don't want to be left
behind tech-wise because my favorite distro is lagging. I need to be
on top of the latest&greatest so I can find my clients the best
possible solutions to their problems."

Regardless of where we set the bounds, do you agree to the *concept*
of having two different modes?

> There are enough benefits even just with C++03.  C++11 etc. extensions still
> can be done incrementally in the future.

For example, one of the major motivations of switching to C++ is to
use exceptions. And exceptions are hard to use properly without move
constructors (yes, compile-time "noexcept" propogation is only in gcc
4.6, but it is quite rare that you need to *prove* it to the compiler
... but that can be done in "development mode" anyway).

And C++11 is, in many ways, a whole new language. The way you write
APIs when you have moves is completely different than the way you
write APIs without moves. And I'm *sure* you know that any "temporary
hack until we're allowed to use rvalue references" will survive for
decades.

-Ben

Re: [C++] System Requirements

[Mark Kettenis]

> Date: Sun, 15 Dec 2013 09:04:09 -0800
> From: Ben Longbons <brlongbons@gmail.com>
> 
> Personally, I don't get why people who are using long-term "stable"
> releases expect to be able to use the latest and greatest version of
> anything. If you only need to *use* gdb, you can just stick to older
> versions (including 7.7) which are still fully-featured releases.

Personally I don't get why we should listen to someone who never ever
contributed a single patch to GDB.  Stop wasting our time.  Come back
after you've actually contributed some actual code to GDB.

Cheers,

Mark

Re: [C++] System Requirements

[Ivo Raisr]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

> Date: Fri, 13 Dec 2013 16:36:46 -0800
> From: Ben Longbons <brlongbons at gmail dot com>
>
> ...
> Under the assumption that most active gdb maintainers intend that
> future gdb releases be written in C++...
>

I am in no way to entitled to comment on this decision.
I hope the community will not regret such move.

But I think it will be of some value (and amusement) to
remind you of the following article about invention of C++
language (see either here:
http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtml
or in the attachment).

Please do not flame the mail forum about your opinions on this article;
send them (and blame) directly to me.
I.

[-- Attachment #2: Invention_of_C++.txt --]
[-- Type: text/plain, Size: 13099 bytes --]

   On the 1st of January, 1998, Bjarne Stroustrup gave
   an interview to the IEEE's 'Computer' magazine.
   Naturally, the editors thought he would be giving
   a retrospective view of seven years of object-oriented
   design, using the language he created. By the end of the
   interview, the interviewer got more than he had
   bargained for and, subsequently, the editor decided to
   suppress its contents, 'for the good of the industry' but,
   as with many of these things, there was a leak. Here is a
   complete transcript of what was said, unedited, and
   unrehearsed, so it isn't as neat as planned interviews.
   You will find it interesting...

   ________________________________________________________________

   Interviewer:

   Well, it's been a few years since you changed theworld of
   software design.  How does it feel, looking back?

   Stroustrup:

   Actually, I was thinking about those days, just before you
   arrived.  Do you remember?  Everyone was writing 'C' and,
   the trouble was, they were pretty damn good at it.
   Universities got pretty good at teaching it, too.  They were
   turning out competent - I stress the word 'competent' -
   graduates at a phenomenal rate.  That's what caused the
   problem.

   Interviewer:

   Problem?

   Stroustrup:

   Yes, problem.  Remember when everyone wrote COBOL?

   Interviewer:

   Of course, I did, too.

   Stroustrup:

   Well, in the beginning, these guys were like
   demi-gods.  Their salaries were high, and they
   were treated like royalty.

   Interviewer:

   Those were the days, eh?

   Stroustrup:

   Right.  So what happened?  IBM got sick of it,
   and invested millions in training programmers, till
   they were a dime a dozen.

   Interviewer:

   That's why I got out.  Salaries dropped within a
   year, to the point where being a journalist actually
   paid better.

   Stroustrup:

   Exactly.  Well, the same happened with 'C' programmers.

   Interviewer:   I see, but what's the point?

   Stroustrup:

   Well, one day, when I was sitting in my office, I
   thought of this little scheme, which would redress
   the balance a little.  I thought 'I wonder what
   would happen, if there were a language so complicated,
   so difficult to learn, that nobody would ever be able
   to swamp the market with programmers?

   Actually, I got some of the ideas from X10, you know,
   X windows.  That was such a bitch of a graphics system,
   that it only just ran on those Sun 3/60 things.  They
   had all the ingredients for what I wanted.  A really
   ridiculously complex syntax, obscure functions, and
   pseudo-OO structure.  Even now, nobody writes raw X-windows
   code.  Motif is the only way to go if you want to retain
   your sanity.

   Interviewer:

   You're kidding...?

   Stroustrup:

   Not a bit of it.  In fact, there was another problem.
   Unix was written in 'C', which meant that any 'C'
   programmer could very easily become a systems programmer.
   Remember what a mainframe systems programmer used to earn?

   Interviewer:

   You bet I do, that's what I used to do.

   Stroustrup:

   OK, so this new language had to divorce itself from Unix,
   by hiding all the system calls that bound the two together
   so nicely.  This would enable guys who only knew about DOS
   to earn a decent living too.

   Interviewer:

   I don't believe you said that...

   Stroustrup:

   Well, it's been long enough, now, and I believe most people
   have figured out for themselves that C++ is a waste of time but,
   I must say, it's taken them a lot longer than I thought it would.

   Interviewer:

   So how exactly did you do it?

   Stroustrup:

   It was only supposed to be a joke, I never thought people would
   take the book seriously. Anyone with half a brain can see that
   object-oriented programming is counter-intuitive, illogical and
   inefficient.

   Interviewer:

   What?

   Stroustrup:

   And as for 're-useable code' --- when did you ever hear of a
   company re-using its code?

   Interviewer:

   Well, never, actually, but...

   Stroustrup:

   There you are then.  Mind you, a few tried, in the early days.
   There was this Oregon company --- Mentor Graphics, I think they
   were called --- really caught a cold trying to rewrite everything
   in C++ in about '90 or '91.  I felt sorry for them really, but
   I thought people would learn from their mistakes.

   Interviewer:

   Obviously, they didn't?

   Stroustrup:

   Not in the slightest.  Trouble is, most companies hush-up all
   their major blunders, and explaining a $30 million loss to the
   shareholders would have been difficult.  Give them their due,
   though, they made it work in the end.

   Interviewer:

   They did?  Well, there you are then, it proves O-O works.

   Stroustrup:

   Well, almost.  The executable was so huge, it took five minutes
   to load, on an HP workstation, with 128MB of RAM.  Then it ran
   like molasses. Actually, I thought this would be a major
   stumbling-block, and I'd get found out within a week, but nobody
   cared.  Sun and HP were only too glad to sell enormously powerful
   boxes, with huge resources just to run trivial programs.  You
   know, when we had our first C++ compiler, at AT&T, I compiled
  'Hello World', and couldn't believe the size of the executable:
   2.1MB

   Interviewer:

   What?  Well, compilers have come a long way, since then.

   Stroustrup:

   They have?  Try it on the latest version of g++ - you won't get
   much change out of half a megabyte. Also, there are several quite
   recent examples for you, from all over the world.  British Tele-
   com had a major disaster on their hands but, luckily, managed to
   scrap the  whole thing and start again. They were luckier than
   Australian Telecom.

   Now I hear that Siemens is building a dinosaur, and getting more
   and more worried as the size of the hardware gets bigger, to
   accommodate the executables.  Isn't multiple inheritance a joy?

   Interviewer:

   Yes, but C++ is basically a sound language.

   Stroustrup:

   You really believe that, don't you?  Have you ever sat down and
   worked on a C++ project?  Here's what happens: First, I've put
   in enough pitfalls to make sure that only the most trivial proj- 
   ects will work first time.  Take operator overloading.  At the
   end of the project, almost every module has it, usually, because
   guys feel they really should do it, as it was in their training
   course.  The same operator then means something totally different
   in every module.  Try pulling that lot together, when you have a
   hundred or so modules.  And as for data hiding, God, I sometimes
   can't help laughing when I hear about the problems companies
   have making their modules talk to each other.

   I think the word 'synergistic' was specially invented to twist
   the knife in a project manager's ribs.

   Interviewer:

   I have to say, I'm beginning to be quite appalled at all this.
   You say you did it to raise programmers' salaries?  That's ob-
   scene.

   Stroustrup:

   Not really.  Everyone has a choice.  I didn't expect the thing to
   get so much out of hand. Anyway, I basically succeeded.  C++ is
   dying off now, but programmers still get high salaries, especial-
   ly those poor devils who have to maintain all this crap.  You do
   realise, it's impossible to maintain a large C++ software module
   if you didn't actually write it?

   Interviewer:

   How come?

   Stroustrup:

   You are out of touch, aren't you?  Remember the typedef?

   Interviewer:

   Yes, of course.

   Stroustrup:

   Remember how long it took to grope through the header files only
   to find that 'RoofRaised' was a double precision number?  Well,
   imagine how long it takes to find all the implicit typedefs in
   all the Classes in a major project.

   Interviewer:

   So how do you reckon you've succeeded?

   Stroustrup:

   The universities haven't been teaching 'C' for such a long time,
   there's now a shortage of decent 'C' programmers.  Especially
   those who know anything about Unix systems programming. How many
   guys would know what to do with 'malloc', when they've used 'new'
   all these years and never bothered to check the return code. In
   fact, most C++ programmers throw away their return codes.  What-
   ever happened to good ol' '-1'?  At least you knew you had an
   error, without bogging the thing down in all that 'throw' 'catch'
   'try' stuff.

   Interviewer:

   But, surely, inheritance does save a lot of time?

   Stroustrup:

   Does it?  Have you ever noticed the difference  between a 'C'
   project plan, and a C++ project plan?  The planning stage for
   a C++ project is three times as long.  Precisely to make sure
   that everything which should be inherited is, and what shouldn't
   isn't.  Then, they still get it wrong. Whoever heard of memory
   leaks in a 'C' program? Now finding them is a major industry.
   Most companies give up, and send the product out, knowing it
   leaks like a sieve, simply to avoid the expense of tracking them
   all down.

   Interviewer:

   There are tools....

   Stroustrup:

   ...Most of which were written in C++.

   Interviewer:

   If we publish this, you'll probably get lynched, you do realise
   that?

   Stroustrup:

   I doubt it.  As I said, C++ is way past its peak now, and no
   company in its right mind would start a C++ project without a
   pilot trial. That should convince them that it's the road to
   disaster.  If not, they deserve all they get.  You know, I tried
   to convince Dennis Ritchie to rewrite Unix in C++.

   Interviewer:

   Oh my God.  What did he say?

   Stroustrup:

   Well, luckily, he has a good sense of humor.  I think both he
   and Brian figured out what I was doing, in the early days, but
   never let on.  He said he'd help me write a C++ version of DOS,
   if I was interested.

   Interviewer:

   Were you?

   Stroustrup:

   Actually, I did write DOS in C++, I'll give you a demo when
   we're through.  I have it running on a Sparc 20 in the computer
   room.  Goes like a rocket on 4 CPU's, and only takes up 70 megs
   of disk.

   Interviewer:

   What's it like on a PC?

   Stroustrup:

   Now you're kidding.  Haven't you ever seen Windows '95?  I think
   of that as my biggest success.  Nearly blew the game before I was
   ready, though.

   Interviewer:

   You know, that idea of a Unix++ has really got me thinking.
   Somewhere out there, there's a guy going to try it.

   Stroustrup:

   Not after they read this interview.

   Interviewer:

   I'm sorry, but I don't see us being able to publish any of this.

   Stroustrup:

   But it's the story of the century.  I only want to be remembered
   by my fellow programmers, for what I've done for them.  You know
   how much a C++ guy can get these days?

   Interviewer:

   Last I heard, a really top guy is worth $80 - $90 an hour.

   Stroustrup:

   See?  And I bet he earns it.  Keeping track of all the gotchas I
   put into C++ is no easy job. And, as I said before, every C++
   programmer feels bound by some mystic promise to use every damn
   element of the language on every project. Actually, that really
   annoys me sometimes, even though it serves my original purpose.
   I almost like the language after all this time.

   Interviewer:

   You mean you didn't before?

   Stroustrup:

   Hated it.  It even looks clumsy, don't you agree?  But when the
   book royalties started to come in... well, you get the picture.

   Interviewer:

   Just a minute.  What about references?  You must admit, you
   improved on 'C' pointers.

   Stroustrup:

   Hmm.  I've always wondered about that.  Originally, I thought I
   had.  Then, one day I was discussing this with a guy who'd written
   C++ from the beginning.  He said he could never remember whether
   his variables were referenced or dereferenced, so he always used
   pointers.  He said the little asterisk always reminded him.

   Interviewer:

   Well, at this point, I usually say 'thank you very much' but it
   hardly seems adequate.

   Stroustrup:

   Promise me you'll publish this.  My conscience is getting the
   better of me these days.

   Interviewer:

   I'll let you know, but I think I know what my editor will say.

   Stroustrup:

   Who'd believe it anyway?  Although, can you send me a copy of that
   tape?

   Interviewer:

   I can do that.

   ________________________________________________________________
   ________________________________________________________________
   ________________________________________________________________

Re: [C++] System Requirements

[Phi Debian]

This is indeed a sad day. I got my own gdb since years, have my own
hack in there, basically getting rid of the TUI and getting my own
proper TUI, not curses based, working much like dbx, xdb, i.e
lightweigth comunication (not graphic) yet able to display source code
efficiently with basic terminal. My hack are 'gdb portable' i.e
forward ported since age. And I only debug C code (so far I was lucky)

This move to gdb written in C++ will indeed move me away from it, time
to look llvm closer :)

May be this will trig also some fork, who knows may be there are some
out there who still want a lightweigth debugger of classic non object
language (say C, pascal, fortran)....

Sounds like GDB caught the same disease as gnome, etc, they want to be modern :)

Cheers,
Phi

Re: [C++] System Requirements

[Eli Zaretskii]

> Date: Fri, 13 Dec 2013 16:34:17 -0800
> From: Ben Longbons <brlongbons@gmail.com>
> 
> I propose that the minimum "development requirements" is either gcc
> 4.6 or 4.7.

IMO, it makes very little sense to require the bleeding edge, or
thereabouts.  I still use GCC 3.4 on one of my main development
machines; the other one was upgraded to 4.7.2 a few months ago, and
I'm still lamenting the two-fold increase in build times that this
caused.

As another data point, the GNU shell server fencepost.gnu.org, a
Trisquel system, offers GCC 4.4.3.

> gcc 4.8.1 is the first fully-compliant C++11 release.

So what?  Why do we need this full compliance is the important part.

Re: [C++] System Requirements

[Eli Zaretskii]

> Date: Sun, 15 Dec 2013 09:04:09 -0800
> From: Ben Longbons <brlongbons@gmail.com>
> Cc: gdb@sourceware.org
> 
> Personally, I don't get why people who are using long-term "stable"
> releases expect to be able to use the latest and greatest version of
> anything. If you only need to *use* gdb, you can just stick to older
> versions (including 7.7) which are still fully-featured releases.

Perhaps you never tried to use outdated versions of GDB too seriously
for too long.  GDB constantly gets more and more useful features and
solves more and more bugs, so using an old version is a PITA.  It's
not like GDB development aims only at supporting newer compiler
versions, you know.  Just look at the commit logs, and you will see.

> But you're saying you're using RHEL5 for your *development* ? I'm not
> used to developers who can even stand not using the latest release.

Get used to that.  Not every developer can determine for herself what
releases she will have installed.  Life intervenes.

> Regardless of where we set the bounds, do you agree to the *concept*
> of having two different modes?

I don't.  There's no reason to have that, and it certainly adds to the
overhead.

Re: [C++] System Requirements

[Ben Longbons]

On Mon, Dec 16, 2013 at 11:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Perhaps you never tried to use outdated versions of GDB too seriously
> for too long.  GDB constantly gets more and more useful features and
> solves more and more bugs, so using an old version is a PITA.
Well, I can state with absolute certainty that there are *some* bugs
in gdb that simply will not be fixed without relying on some subset of
C++11 features.

It's not that they couldn't theoretically be fixed otherwise, they
just wouldn't be detected. For a while I had to maintain two branches
of my own software, and I remember specifically backporting one fix to
the pre-C++11 stable branch for a problem that many users had noticed,
but which eluded bughunts until I used some C++11 stuff.

In some cases it is possible to hide the feature behind the
development mode check, in some cases it is not. GCC 4.3 and 4.4
introduce a lot of features that can't be used conditionally.

> It's
> not like GDB development aims only at supporting newer compiler
> versions, you know.  Just look at the commit logs, and you will see.
I haven't been able to get the specific information I looked for as to
exactly which versions *are* supported and which have been for
previous releases.

>> Regardless of where we set the bounds, do you agree to the *concept*
>> of having two different modes?
>
> I don't.  There's no reason to have that, and it certainly adds to the
> overhead.
I do strongly believe it is beneficial to keep the two modes very
similar, but with the specific differences I have in mind, it would be
rather unlikely to commit something that failed in one mode and worked
in the other.

-Ben

Re: [C++] System Requirements

[Andrew Pinski]

On Sun, Dec 15, 2013 at 4:28 AM, Michael Veksler
<mveksler@tx.technion.ac.il> wrote:
> On 14/12/13 02:40, Ben Longbons wrote:
>>
>> <snip>
>>
>> NetBSD 6.1.1 (2013-08-22): gcc 4.8.1
>> NetBSD 5.1 (2010-11-19): gcc 3.3.6
>>
>> OpenBSD 5.4 (2013-11-01): gcc 4.2.1
>> OpenBSD 4.7 (2010-05-19): gcc 3.3.5
>>
>>
> I recommend to avoid gcc versions prior to gcc-3.4. Over a decade ago I had
> to port code from gcc-3.2 to gcc-3.4
> without losing support for gcc-3.2. Even though the code was much smaller
> than gdb it was a pain to support
> both versions in parallel:
> 1. gcc-3.2 has an old C++ parser and supports a dialect of C++ which
> predates ISO C++.

> 2. gcc-3.2 does not have namespace
> 3. Requires STL as a separate library
> 4. Containers of the STL libraries do not understand allocators, and can't
> be taught to due to limitations in old C++

These above 4 are incorrect as the new libstdc++ came in with 3.0 and
that is when namespace support came in.

> 5. Templates have significantly different semantics, and define a one-pass
> parsing (unlike 2 pass in ISO C++).

It is still one pass parsing, just the semantics is done at two different times.

I think we should support anything 3.0 and above.  Since we won't be
using STL or templates that much.

Thanks,
Andrew Pinski

>
> Avoid gcc-3.2
>
> Michael

Re: [C++] System Requirements

[Ben Longbons]

On Mon, Dec 16, 2013 at 6:29 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> I think we should support anything 3.0 and above.  Since we won't be
> using STL or templates that much.
Really? I can see quite a few cases where gdb will either have to use
the STL or reinvent it; the big one is vec.h but it's far from alone.

I know there are reasons to avoid or reimplement specific *parts* of
the STL, but I haven't seen justification to avoid it in general.

And I think that it is quite dangerous to try to support building gdb
on a platform that its developers do not regularly use. gcc 4.4 is
common; 4.[678] is rising, and 4.1 looks supportable, just not by me.
I can't even build gcc 4.2 or earlier on any of my systems, though I
admit I haven't deeply investigated what makes them different from 4.3

Anyway, this sounds like a topic for the not-yet written thread [C++]
Style Guide ... the only thing I've heard is that gdb is *not* going
to follow gcc, because it has different requirements, such as
exceptions (which, incidentally, must happen before anything else in
step 5).


But back on topic ... I started this thread intending to ask "which
versions of GCC do we *need* to support?", not "which versions of GCC
can we afford to support?" ... I never expected anyone to defend
versions before 3.4

A lower GCC version requirement means that gdb maintainers will have
to spend more time trying to work around the quirks of older GCC
versions and trying to badly reimplement features that are already in
later GCC versions.

-Ben

Re: [C++] System Requirements

[Sergio Durigan Junior]

On Monday, December 16 2013, Phi Debian wrote:

> This move to gdb written in C++ will indeed move me away from it, time
> to look llvm closer :)

... always keeping in mind that LLVM/LLDB are written in C++.

-- 
Sergio

Re: [C++] System Requirements

[Michael Veksler]

On 17/12/13 06:02, Ben Longbons wrote:
> On Mon, Dec 16, 2013 at 6:29 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>> I think we should support anything 3.0 and above.  Since we won't be
>> using STL or templates that much.
> Really? I can see quite a few cases where gdb will either have to use
> the STL or reinvent it; the big one is vec.h but it's far from alone.
>
> I know there are reasons to avoid or reimplement specific *parts* of
> the STL, but I haven't seen justification to avoid it in general.
>
> And I think that it is quite dangerous to try to support building gdb
> on a platform that its developers do not regularly use. gcc 4.4 is
> common; 4.[678] is rising, and 4.1 looks supportable, just not by me.
> I can't even build gcc 4.2 or earlier on any of my systems, though I
> admit I haven't deeply investigated what makes them different from 4.3
>
> Anyway, this sounds like a topic for the not-yet written thread [C++]
> Style Guide ... the only thing I've heard is that gdb is *not* going
> to follow gcc, because it has different requirements, such as
> exceptions (which, incidentally, must happen before anything else in
> step 5).
>
>
> But back on topic ... I started this thread intending to ask "which
> versions of GCC do we *need* to support?", not "which versions of GCC
> can we afford to support?" ... I never expected anyone to defend
> versions before 3.4
>
> A lower GCC version requirement means that gdb maintainers will have
> to spend more time trying to work around the quirks of older GCC
> versions and trying to badly reimplement features that are already in
> later GCC versions.
>
Andrew was right, and I was wrong. I confused between the pain
I had when I supported  gcc-2.95 (or was it egcs?) with the smaller
pain of supporting gcc-3.2/gcc-3.3. It was too long ago to
remember all the gory details.

Nevertheless, supporting pre-gcc-3.4 compilers is still a pain.
Not only because language semantics is different (two-phase
name lookup in templates vs. one) but because you can't easily
build old compilers on modern machines. And if you don't test
your  code with a pre-gcc-3.4 then your code won't work with
earlier compilers.

Michael

Re: [C++] System Requirements

[Ben Longbons]

On Wed, Dec 18, 2013 at 4:46 AM, Michael Veksler
<mveksler@tx.technion.ac.il> wrote:
> Nevertheless, supporting pre-gcc-3.4 compilers is still a pain.
> Not only because language semantics is different (two-phase
> name lookup in templates vs. one) but because you can't easily
> build old compilers on modern machines. And if you don't test
> your  code with a pre-gcc-3.4 then your code won't work with
> earlier compilers.

Right. And my point is that not enough people use a pre-4.1 compiler
either, even though 3.4 is *supposed* to mark the beginning of
compliance.

I'm definitely not happy about 4.1 - it would make gdb code
significantly worse than it could be - but at least I can be confident
that there is a userbase from RHEL 5.

-Ben