Eclipse uses the GDB version to figure out what features are supported by GDB. I keep running into parsing problems because the version printout is not standard between different GDB builds. I would be safer to have a --shortversion flag that would simply provide the number part of the version. For example > gdb --shortversion 7.6.1 > gdb --shortversion 7.6.50.20131126-cvs
I'm curious why you use versions and what you use them for. On the whole I think it would be better if you could use feature tests instead. In theory I think the allowable versions are defined in the internals manual: https://sourceware.org/gdb/wiki/Internals%20Versions I'm afraid I don't know how closely reality conforms to this. Also see the vendor branch page: https://sourceware.org/gdb/wiki/Internals%20Vendor-Branches
(In reply to Tom Tromey from comment #1) > I'm curious why you use versions and what you use them for. Eclipse CDT bases itself on the GDB version to know what features are available or not. For example, Reverse debugging will only be possible to enable if we are dealing with GDB version >= 7.0; multi-process needs >= 7.2; showing information on cores needs >= 7.1 > On the whole I think it would be better if you could use > feature tests instead. Yes, the solution we use works for FSF GDB but will not work so well for any modified GDB. However, I'm not sure there is a reliable way to figure out feature availability for everything CDT uses from GDB. Futhermore, there are many drawbacks to test for features in a 'brute force' fashion: error printouts visible to the user (or the complexity of silencing them), affecting the GDB state, delayed startup time to run through the many feature tests. > In theory I think the allowable versions are defined in the > internals manual: https://sourceware.org/gdb/wiki/Internals%20Versions > I'm afraid I don't know how closely reality conforms to this. > Also see the vendor branch page: > https://sourceware.org/gdb/wiki/Internals%20Vendor-Branches Over the years, this is the list of formats we've seen in the wild. GNU gdb 6.8.50.20080730 GNU gdb (GDB) 6.8.50.20080730-cvs GNU gdb (Ericsson GDB 1.0-10) 6.8.50.20080730-cvs GNU gdb (GDB) Fedora (7.0-3.fc12) GNU gdb 6.8.0.20080328-cvs (cygwin-special) GNU gdb 7.0 GNU gdb Fedora (6.8-27.el5) GNU gdb Red Hat Linux (6.3.0.0-1.162.el4rh) GNU gdb (GDB) STMicroelectronics/Linux Base 7.4-71 [build Mar 1 2013] and then there's Apple's GDB, but I'm not sure this one has a future: GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007) GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009) GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009) GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC 2010) GNU gdb 7.0 (Apple version gdb-1) (Fri Sep 18 20:40:51 UTC 2009) GNU gdb 7.0-20050815 (Apple version gdb-01) (Fri Sep 18 20:40:51 UTC 2009) Having a --shortversion option would reduce the risk of some unexpected format with special characters or interchanged ordering.
Fixed by above commit
Ooops disregard last comment and status change I used the wrong bug :(...