* [PATCH 0/1] Build GDB as a C++ program by default @ 2016-04-18 17:27 Pedro Alves 2016-04-18 17:27 ` [PATCH 1/1] " Pedro Alves 2016-04-19 13:34 ` [PATCH 0/1] " Simon Marchi 0 siblings, 2 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-18 17:27 UTC (permalink / raw) To: gdb-patches It's been a long ride, but GDB now builds cleanly as a C++ program on most supported systems. There are a few host-specific files that may be missing the occasional cast, but for all I know, most of the codebase has been converted and builds cleanly, with no undefined behavior and no hacks. It's time to try building GDB with a C++ compiler by default, which is what the the following trivial patch does. Following the discussion on the gdb@ list, this flips the default on all hosts, unconditionally. Note that it's still possible to revert back to building with a C compiler, by configuring with --enable-build-with-cxx=no. For the moment, we have a Fedora buildslave specifically set up to catch C-mode build failures on Fedora, so C-mode breakage should still be noticed and fixed promptly. The decision of when to drop C-mode support will be done at some other moment, possibly only after the next release. Pedro Alves (1): Build GDB as a C++ program by default gdb/build-with-cxx.m4 | 2 +- gdb/configure | 2 +- gdb/gdbserver/configure | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 2.5.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/1] Build GDB as a C++ program by default 2016-04-18 17:27 [PATCH 0/1] Build GDB as a C++ program by default Pedro Alves @ 2016-04-18 17:27 ` Pedro Alves 2016-04-19 7:34 ` Yao Qi 2016-04-19 13:34 ` [PATCH 0/1] " Simon Marchi 1 sibling, 1 reply; 22+ messages in thread From: Pedro Alves @ 2016-04-18 17:27 UTC (permalink / raw) To: gdb-patches This makes --enable-build-with-cxx be "yes" by default. One must now configure with --enable-build-with-cxx=no in order to build with a C compiler. gdb/ChangeLog: 2016-04-18 Pedro Alves <palves@redhat.com> * build-with-cxx.m4 (GDB_AC_BUILD_WITH_CXX): Default to yes unless building on some hosts. * configure: Renegerate. gdb/gdbserver/ChangeLog: 2016-04-18 Pedro Alves <palves@redhat.com> * configure: Renegerate. --- gdb/build-with-cxx.m4 | 2 +- gdb/configure | 2 +- gdb/gdbserver/configure | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gdb/build-with-cxx.m4 b/gdb/build-with-cxx.m4 index 6eb9143..6077278 100644 --- a/gdb/build-with-cxx.m4 +++ b/gdb/build-with-cxx.m4 @@ -29,7 +29,7 @@ AC_DEFUN([GDB_AC_BUILD_WITH_CXX], *) AC_MSG_ERROR([bad value $enableval for --enable-build-with-cxx]) ;; esac], - [enable_build_with_cxx=no]) + [enable_build_with_cxx=yes]) if test "$enable_build_with_cxx" = "yes"; then COMPILER='$(CXX)' diff --git a/gdb/configure b/gdb/configure index 8c2ec0f..3cf95e7 100755 --- a/gdb/configure +++ b/gdb/configure @@ -4965,7 +4965,7 @@ if test "${enable_build_with_cxx+set}" = set; then : as_fn_error "bad value $enableval for --enable-build-with-cxx" "$LINENO" 5 ;; esac else - enable_build_with_cxx=no + enable_build_with_cxx=yes fi diff --git a/gdb/gdbserver/configure b/gdb/gdbserver/configure index 2082335..746218e 100755 --- a/gdb/gdbserver/configure +++ b/gdb/gdbserver/configure @@ -4784,7 +4784,7 @@ if test "${enable_build_with_cxx+set}" = set; then : as_fn_error "bad value $enableval for --enable-build-with-cxx" "$LINENO" 5 ;; esac else - enable_build_with_cxx=no + enable_build_with_cxx=yes fi -- 2.5.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/1] Build GDB as a C++ program by default 2016-04-18 17:27 ` [PATCH 1/1] " Pedro Alves @ 2016-04-19 7:34 ` Yao Qi 0 siblings, 0 replies; 22+ messages in thread From: Yao Qi @ 2016-04-19 7:34 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches Pedro Alves <palves@redhat.com> writes: > * build-with-cxx.m4 (GDB_AC_BUILD_WITH_CXX): Default to yes unless > building on some hosts. The description is out of date. Patch is good to me. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-18 17:27 [PATCH 0/1] Build GDB as a C++ program by default Pedro Alves 2016-04-18 17:27 ` [PATCH 1/1] " Pedro Alves @ 2016-04-19 13:34 ` Simon Marchi 2016-04-19 14:18 ` Pedro Alves 1 sibling, 1 reply; 22+ messages in thread From: Simon Marchi @ 2016-04-19 13:34 UTC (permalink / raw) To: Pedro Alves, gdb-patches On 16-04-18 01:27 PM, Pedro Alves wrote: > It's been a long ride, but GDB now builds cleanly as a C++ program on > most supported systems. > > There are a few host-specific files that may be missing the occasional > cast, but for all I know, most of the codebase has been converted and > builds cleanly, with no undefined behavior and no hacks. > > It's time to try building GDB with a C++ compiler by default, which is > what the the following trivial patch does. > > Following the discussion on the gdb@ list, this flips the default on > all hosts, unconditionally. > > Note that it's still possible to revert back to building with a C > compiler, by configuring with --enable-build-with-cxx=no. For the > moment, we have a Fedora buildslave specifically set up to catch > C-mode build failures on Fedora, so C-mode breakage should still be > noticed and fixed promptly. > > The decision of when to drop C-mode support will be done at some other > moment, possibly only after the next release. > > Pedro Alves (1): > Build GDB as a C++ program by default > > gdb/build-with-cxx.m4 | 2 +- > gdb/configure | 2 +- > gdb/gdbserver/configure | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > Does that mean that all supported hosts have been tested to build in C++? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 13:34 ` [PATCH 0/1] " Simon Marchi @ 2016-04-19 14:18 ` Pedro Alves 2016-04-19 14:48 ` Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-19 14:18 UTC (permalink / raw) To: Simon Marchi, gdb-patches On 04/19/2016 02:34 PM, Simon Marchi wrote: > On 16-04-18 01:27 PM, Pedro Alves wrote: >> It's been a long ride, but GDB now builds cleanly as a C++ program on >> most supported systems. >> >> There are a few host-specific files that may be missing the occasional >> cast, but for all I know, most of the codebase has been converted and >> builds cleanly, with no undefined behavior and no hacks. >> >> It's time to try building GDB with a C++ compiler by default, which is >> what the the following trivial patch does. >> >> Following the discussion on the gdb@ list, this flips the default on >> all hosts, unconditionally. > Does that mean that all supported hosts have been tested to build in C++? "all" is a bit too wide. There are simply too many to tell: https://sourceware.org/gdb/wiki/Systems I don't know whether VAX or m68k BSD build cleanly, for instance. I don't know whether they build cleanly in C-mode, either -- I wouldn't be surprised if several of the listed systems on that table didn't build today. It sort of goes back to what you'd call "supported host". If nobody's actively caring about such hosts, then it's just going to happen that changes elsewhere will accidentally break them. But at least we know that x86-64 NetBSD and FreeBSD build and run in C++ mode, which I think is sufficient proxy for all BSDs, in the sense that if something else is needed it'll probably be a couple malloc casts here and there in the corresponding $arch-nat.c files. AFAIK, all GNU/Linux ports build cleanly. (Except maybe Xtensa, which may need your small cast patch on my github. Is that one still needed?). MinGW (w64) builds and runs cleanly for me too. I think the ones pending confirmation are Solaris and QNX. If we do find some host does trip on some big problem, then we can always flip it back to C by default. Given that the request for testing with --enable-build-with-cxx was sent five months ago, and nobody reported breakage (nor success) on Solaris/QNX, I think we need to bite the bullet and move forward. We won't know unless we try. WDYT? Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 14:18 ` Pedro Alves @ 2016-04-19 14:48 ` Eli Zaretskii 2016-04-19 15:03 ` Pedro Alves 2016-04-19 15:41 ` Simon Marchi [not found] ` <AC542571535E904D8E8ADAE745D60B19445B1C11@IRSMSX104.ger.corp.intel.com> ` (2 subsequent siblings) 3 siblings, 2 replies; 22+ messages in thread From: Eli Zaretskii @ 2016-04-19 14:48 UTC (permalink / raw) To: Pedro Alves; +Cc: simon.marchi, gdb-patches > From: Pedro Alves <palves@redhat.com> > Date: Tue, 19 Apr 2016 15:18:35 +0100 > > MinGW (w64) builds and runs cleanly for me too. Did you look at what libraries it depends on? Doesn't it pull in libgcc DLL and libstdc++ DLL? If it does, that'll put a huge damper on those who make precompiled binaries of GDB available for Windows users, because you need to accompany that with the full GCC source tarball, which weighs in at more than 80MB. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 14:48 ` Eli Zaretskii @ 2016-04-19 15:03 ` Pedro Alves 2016-04-19 15:23 ` Eli Zaretskii 2016-04-19 15:41 ` Simon Marchi 1 sibling, 1 reply; 22+ messages in thread From: Pedro Alves @ 2016-04-19 15:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: simon.marchi, gdb-patches On 04/19/2016 03:48 PM, Eli Zaretskii wrote: >> From: Pedro Alves <palves@redhat.com> >> Date: Tue, 19 Apr 2016 15:18:35 +0100 >> >> MinGW (w64) builds and runs cleanly for me too. > > Did you look at what libraries it depends on? Doesn't it pull in > libgcc DLL and libstdc++ DLL? If it does, that'll put a huge damper > on those who make precompiled binaries of GDB available for Windows > users, because you need to accompany that with the full GCC source > tarball, which weighs in at more than 80MB. GDB links with libgcc even when built as a C program. How's C++ any different? Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:03 ` Pedro Alves @ 2016-04-19 15:23 ` Eli Zaretskii 2016-04-19 15:40 ` Pedro Alves 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2016-04-19 15:23 UTC (permalink / raw) To: Pedro Alves; +Cc: simon.marchi, gdb-patches > Cc: simon.marchi@ericsson.com, gdb-patches@sourceware.org > From: Pedro Alves <palves@redhat.com> > Date: Tue, 19 Apr 2016 16:03:41 +0100 > > On 04/19/2016 03:48 PM, Eli Zaretskii wrote: > >> From: Pedro Alves <palves@redhat.com> > >> Date: Tue, 19 Apr 2016 15:18:35 +0100 > >> > >> MinGW (w64) builds and runs cleanly for me too. > > > > Did you look at what libraries it depends on? Doesn't it pull in > > libgcc DLL and libstdc++ DLL? If it does, that'll put a huge damper > > on those who make precompiled binaries of GDB available for Windows > > users, because you need to accompany that with the full GCC source > > tarball, which weighs in at more than 80MB. > > GDB links with libgcc even when built as a C program. Not here, it doesn't. It is linked statically against libgcc. (I don't use MinGW64, but I don't think it matters.) Here's what 'objdump -x | fgrep "DLL Name:"' says about the latest GDB 7.11 I built: (standard input):73: DLL Name: libguile-2.0-22.dll (standard input):204: DLL Name: KERNEL32.dll (standard input):298: DLL Name: msvcrt.dll (standard input):323: DLL Name: msvcrt.dll (standard input):450: DLL Name: libncurses5.dll (standard input):501: DLL Name: USER32.dll (standard input):510: DLL Name: WS2_32.dll (standard input):531: DLL Name: zlib1.dll (standard input):542: DLL Name: python26.dll This is a build that (as you see) supports TUI, Python, and Guile, so it's as full as it gets. > How's C++ any different? With C, you can get away by using "CC='gcc -static-libgcc'" at configure time, but can you do the same with -static-libstdc++? I had bad experience with that in the past (the binary still depended on libstdc++ DLL), but maybe that was when building shared libraries, not .exe programs. Thus my question (sorry, didn't yet have time to build a recent development snapshot of GDB). Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:23 ` Eli Zaretskii @ 2016-04-19 15:40 ` Pedro Alves 2016-04-19 15:59 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Pedro Alves @ 2016-04-19 15:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: simon.marchi, gdb-patches On 04/19/2016 04:23 PM, Eli Zaretskii wrote: >> Cc: simon.marchi@ericsson.com, gdb-patches@sourceware.org >> From: Pedro Alves <palves@redhat.com> >> Date: Tue, 19 Apr 2016 16:03:41 +0100 >> >> On 04/19/2016 03:48 PM, Eli Zaretskii wrote: >>>> From: Pedro Alves <palves@redhat.com> >>>> Date: Tue, 19 Apr 2016 15:18:35 +0100 >>>> >>>> MinGW (w64) builds and runs cleanly for me too. >>> >>> Did you look at what libraries it depends on? Doesn't it pull in >>> libgcc DLL and libstdc++ DLL? If it does, that'll put a huge damper >>> on those who make precompiled binaries of GDB available for Windows >>> users, because you need to accompany that with the full GCC source >>> tarball, which weighs in at more than 80MB. >> >> GDB links with libgcc even when built as a C program. > > Not here, it doesn't. It is linked statically against libgcc. I don't see how linking statically removes the requirement to provide access to sources. > (I > don't use MinGW64, but I don't think it matters.) Here's what > 'objdump -x | fgrep "DLL Name:"' says about the latest GDB 7.11 I > built: > ... > This is a build that (as you see) supports TUI, Python, and Guile, so > it's as full as it gets. I get, on a C++ gdb build: $ objdump -x gdb.exe | fgrep "DLL Name:" DLL Name: KERNEL32.dll DLL Name: msvcrt.dll DLL Name: libwinpthread-1.dll DLL Name: USER32.dll DLL Name: WS2_32.dll > >> How's C++ any different? > > With C, you can get away by using "CC='gcc -static-libgcc'" at > configure time, but can you do the same with -static-libstdc++? You shouldn't even need that. We already link with -static-libstdc++ -static-libgcc: x86_64-w64-mingw32-g++ -g -O2 -static-libstdc++ -static-libgcc -Wl,--stack,12582912 \ -o gdb.exe gdb.o armbsd-tdep.o arm.o arm-linux.o arm-linux-tdep.o arm-get-next-pcs.o arm-symbian-tdep.o armnbsd-tdep.o ... And we also link that way when building as a C program. We haven't done anything specific to have that on the gdb side, it comes from the top level somewhere, I think originally for GCC, long ago. Since GCC is already building this way for a long time, it should not be a problem for GDB either. Or at least if it is a problem, it's one you would already have with GCC. > I had > bad experience with that in the past (the binary still depended on > libstdc++ DLL), but maybe that was when building shared libraries, not > .exe programs. Thus my question (sorry, didn't yet have time to build > a recent development snapshot of GDB). Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:40 ` Pedro Alves @ 2016-04-19 15:59 ` Eli Zaretskii 2016-04-19 16:20 ` Pedro Alves 2016-04-19 16:31 ` Eli Zaretskii 0 siblings, 2 replies; 22+ messages in thread From: Eli Zaretskii @ 2016-04-19 15:59 UTC (permalink / raw) To: Pedro Alves; +Cc: simon.marchi, gdb-patches > From: Pedro Alves <palves@redhat.com> > Cc: simon.marchi@ericsson.com, gdb-patches@sourceware.org > Date: Tue, 19 Apr 2016 16:40:30 +0100 > > >> GDB links with libgcc even when built as a C program. > > > > Not here, it doesn't. It is linked statically against libgcc. > > I don't see how linking statically removes the requirement to > provide access to sources. It does, because there's a special clause for that in the L?GPL, whch only holds for static linking. > I get, on a C++ gdb build: > > $ objdump -x gdb.exe | fgrep "DLL Name:" > DLL Name: KERNEL32.dll > DLL Name: msvcrt.dll > DLL Name: libwinpthread-1.dll > DLL Name: USER32.dll > DLL Name: WS2_32.dll Then there's no problem, and I apologize for the noise. I thought your previous message meant that there was a dynamic dependency on libstdc++ DLL, sorry for my misunderstanding. > >> How's C++ any different? > > > > With C, you can get away by using "CC='gcc -static-libgcc'" at > > configure time, but can you do the same with -static-libstdc++? > > You shouldn't even need that. We already link with > -static-libstdc++ -static-libgcc: IME, programs that use libtool cannot easily do that, because libtool removes any switches it doesn't know about from the GCC command line. > x86_64-w64-mingw32-g++ -g -O2 -static-libstdc++ -static-libgcc -Wl,--stack,12582912 \ > -o gdb.exe gdb.o armbsd-tdep.o arm.o arm-linux.o arm-linux-tdep.o arm-get-next-pcs.o arm-symbian-tdep.o armnbsd-tdep.o > ... > > And we also link that way when building as a C program. > > We haven't done anything specific to have that on the gdb side, it > comes from the top level somewhere, I think originally for GCC, long > ago. Good, then the problem I feared doesn't really exist. Thanks for clearing that up. > Since GCC is already building this way for a long time, it should not > be a problem for GDB either. Or at least if it is a problem, it's > one you would already have with GCC. I see too many precompiled binaries out there that depend on libgcc DLL. Most people think it is not a problem, so we don't hear any complaints. So the fact that GCC builds this way is in itself not an evidence the problem doesn't exist. For someone like myself, who tries to be 100% GPL compatible with the binaries I make available, having a GCC dependency is a huge downside, so I go an extra mile to avoid that. Once again, I'm happy to know there' no such problem with GDB. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:59 ` Eli Zaretskii @ 2016-04-19 16:20 ` Pedro Alves 2016-04-19 16:31 ` Eli Zaretskii 1 sibling, 0 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-19 16:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: simon.marchi, gdb-patches On 04/19/2016 04:59 PM, Eli Zaretskii wrote: > Once again, I'm happy to know there' no such problem with GDB. Great, me too. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:59 ` Eli Zaretskii 2016-04-19 16:20 ` Pedro Alves @ 2016-04-19 16:31 ` Eli Zaretskii 1 sibling, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2016-04-19 16:31 UTC (permalink / raw) To: palves; +Cc: simon.marchi, gdb-patches > Date: Tue, 19 Apr 2016 18:59:24 +0300 > From: Eli Zaretskii <eliz@gnu.org> > CC: simon.marchi@ericsson.com, gdb-patches@sourceware.org > > > I don't see how linking statically removes the requirement to > > provide access to sources. > > It does, because there's a special clause for that in the L?GPL, whch > only holds for static linking. Or maybe I'm wrong and this clause is in the libgcc license, I no longer remember. But the exemption does exist, and it does cover only static linking. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 14:48 ` Eli Zaretskii 2016-04-19 15:03 ` Pedro Alves @ 2016-04-19 15:41 ` Simon Marchi 2016-04-19 16:32 ` Eli Zaretskii 1 sibling, 1 reply; 22+ messages in thread From: Simon Marchi @ 2016-04-19 15:41 UTC (permalink / raw) To: Eli Zaretskii, Pedro Alves; +Cc: gdb-patches On 16-04-19 10:48 AM, Eli Zaretskii wrote: >> From: Pedro Alves <palves@redhat.com> >> Date: Tue, 19 Apr 2016 15:18:35 +0100 >> >> MinGW (w64) builds and runs cleanly for me too. > > Did you look at what libraries it depends on? Doesn't it pull in > libgcc DLL and libstdc++ DLL? If it does, that'll put a huge damper > on those who make precompiled binaries of GDB available for Windows > users, because you need to accompany that with the full GCC source > tarball, which weighs in at more than 80MB. > I wonder why you say that those who distribute a precompiled gdb would also have to distribute the gcc source. Do you mean they would have to host it alongside the precompiled binary, or they would have to include it in the package users download? Isn't it enough that it's available at gcc.gnu.org and/or mingw.org? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:41 ` Simon Marchi @ 2016-04-19 16:32 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2016-04-19 16:32 UTC (permalink / raw) To: Simon Marchi; +Cc: palves, gdb-patches > CC: <gdb-patches@sourceware.org> > From: Simon Marchi <simon.marchi@ericsson.com> > Date: Tue, 19 Apr 2016 11:41:37 -0400 > > I wonder why you say that those who distribute a precompiled gdb would > also have to distribute the gcc source. Do you mean they would have to > host it alongside the precompiled binary, or they would have to include > it in the package users download? The former, of course. > Isn't it enough that it's available at gcc.gnu.org and/or mingw.org? No, not according to the GPL. You must make sure the users will be able to access the exact sources used to build the libraries, and there's no practical way to ensure that when you point at a site whose contents you don't control. E.g., nothing prevents mingw.org to remove the version of GCC I used to build GDB from their site, and then my link points to the great void. ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <AC542571535E904D8E8ADAE745D60B19445B1C11@IRSMSX104.ger.corp.intel.com>]
[parent not found: <5716425B.3050707@intel.com>]
[parent not found: <57164325.8020408@redhat.com>]
* Re: [PATCH 0/1] Build GDB as a C++ program by default [not found] ` <57164325.8020408@redhat.com> @ 2016-04-19 15:20 ` Walfred Tedeschi 2016-04-20 19:56 ` Pedro Alves 0 siblings, 1 reply; 22+ messages in thread From: Walfred Tedeschi @ 2016-04-19 15:20 UTC (permalink / raw) To: Pedro Alves, Simon Marchi; gdb-patches, gdb-patches Am 4/19/2016 um 4:39 PM schrieb Pedro Alves: > On 04/19/2016 03:36 PM, Walfred Tedeschi wrote: > >> Pedro, >> >> Do you have some data about building GDB on OsX with >> --enable-build-with-cxx? >> >> If not I could give it a try! > > Please do give it a try. Thanks! > There is some issues, i will investigating a bit further. By now i was compiling with Clang, will also try to compile with gcc. I will make a summary of the findings. Best regards, -Fred Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:20 ` Walfred Tedeschi @ 2016-04-20 19:56 ` Pedro Alves 2016-04-20 22:16 ` Pedro Alves 2016-04-21 15:18 ` John Baldwin 0 siblings, 2 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-20 19:56 UTC (permalink / raw) To: Walfred Tedeschi, Simon Marchi; gdb-patches, gdb-patches On 04/19/2016 04:20 PM, Walfred Tedeschi wrote: > Am 4/19/2016 um 4:39 PM schrieb Pedro Alves: >> On 04/19/2016 03:36 PM, Walfred Tedeschi wrote: >> >>> Pedro, >>> >>> Do you have some data about building GDB on OsX with >>> --enable-build-with-cxx? >>> >>> If not I could give it a try! >> >> Please do give it a try. Thanks! >> > > There is some issues, i will investigating a bit further. > By now i was compiling with Clang, will also try to compile with gcc. I managed to build a linux x darwin cross compiler here, using the osxcross tool. Indeed, clang++ stumbles on a bunch of issues. But then again, so does clang in C-mode. With gcc/g++ (5.3.0), and I see a few warnings/errors. Configuring gdb with: /home/pedro/gdb/mygit/cxx-convertion/src/configure --host=x86_64-apple-darwin15 CFLAGS="-g3 -O0" CXXFLAGS="-g3 -O0" --enable-build-with-cxx=no --enable-targets=all --disable-ld --disable-binutils --disable-gas First off, I see a set of: /home/pedro/gdb/mygit/cxx-convertion/src/gdb/main.c:486:27: warning: 'void* sbrk(int)' is deprecated [-Wdeprecated-declarations] lim_at_start = (char *) sbrk (0); ^ but I get that in C-mode too, so I'll ignore. So, compiling with: $ make -k WERROR_CFLAGS="-Wno-deprecated-declarations" 2>diagnostics.txt 1>/dev/null I see just a few warnings / errors, and they all look easily fixable: /home/pedro/gdb/mygit/cxx-convertion/src/gdb/aarch64-tdep.c: In function 'unsigned int aarch64_record_load_store(insn_decode_record*)': /home/pedro/gdb/mygit/cxx-convertion/src/gdb/aarch64-tdep.c:3479:78: error: invalid conversion from 'uint64_t* {aka long long unsigned int*}' to 'ULONGEST* {aka long unsigned int*}' [-fpermissive] bits (aarch64_insn_r->aarch64_insn, 16, 20), ®_rm_val); /home/pedro/gdb/mygit/cxx-convertion/src/gdb/darwin-nat.c: In function 'void darwin_resume_thread(inferior*, darwin_thread_t*, int, int)': /home/pedro/gdb/mygit/cxx-convertion/src/gdb/darwin-nat.c:731:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (caddr_t)thread->gdb_port, nsignal); ^ /home/pedro/gdb/mygit/cxx-convertion/src/gdb/darwin-nat.c: In function 'ptid_t darwin_decode_message(mach_msg_header_t*, darwin_thread_t**, inferior**, target_waitstatus*)': /home/pedro/gdb/mygit/cxx-convertion/src/gdb/darwin-nat.c:1016:25: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive] status->value.sig = WTERMSIG (wstatus); /home/pedro/gdb/mygit/cxx-convertion/src/gdb/darwin-nat.c: In function 'void darwin_resume_thread(inferior*, darwin_thread_t*, int, int)': /home/pedro/gdb/mygit/cxx-convertion/src/gdb/darwin-nat.c:731:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (caddr_t)thread->gdb_port, nsignal); ^ I'll send patches later. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-20 19:56 ` Pedro Alves @ 2016-04-20 22:16 ` Pedro Alves 2016-04-21 15:18 ` John Baldwin 1 sibling, 0 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-20 22:16 UTC (permalink / raw) To: Walfred Tedeschi, Simon Marchi, gdb-patches On 04/20/2016 08:56 PM, Pedro Alves wrote: > On 04/19/2016 04:20 PM, Walfred Tedeschi wrote: >> Am 4/19/2016 um 4:39 PM schrieb Pedro Alves: >>> On 04/19/2016 03:36 PM, Walfred Tedeschi wrote: >>>> >>>> Do you have some data about building GDB on OsX with >>>> --enable-build-with-cxx? > > I managed to build a linux x darwin cross compiler here, using the > osxcross tool. > ... > > So, compiling with: > > $ make -k WERROR_CFLAGS="-Wno-deprecated-declarations" 2>diagnostics.txt 1>/dev/null > > I see just a few warnings / errors, and they all look easily fixable: > ... > > I'll send patches later. > All fixed now. Turned out all but one trigger in C-mode as well, and, the one that triggers in C++-mode only, was actually a GDB bug. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-20 19:56 ` Pedro Alves 2016-04-20 22:16 ` Pedro Alves @ 2016-04-21 15:18 ` John Baldwin 2016-04-21 16:41 ` Pedro Alves 1 sibling, 1 reply; 22+ messages in thread From: John Baldwin @ 2016-04-21 15:18 UTC (permalink / raw) To: gdb-patches; +Cc: Pedro Alves, Walfred Tedeschi, Simon Marchi; gdb-patches On Wednesday, April 20, 2016 08:56:03 PM Pedro Alves wrote: > On 04/19/2016 04:20 PM, Walfred Tedeschi wrote: > > Am 4/19/2016 um 4:39 PM schrieb Pedro Alves: > >> On 04/19/2016 03:36 PM, Walfred Tedeschi wrote: > >> > >>> Pedro, > >>> > >>> Do you have some data about building GDB on OsX with > >>> --enable-build-with-cxx? > >>> > >>> If not I could give it a try! > >> > >> Please do give it a try. Thanks! > >> > > > > There is some issues, i will investigating a bit further. > > By now i was compiling with Clang, will also try to compile with gcc. > > I managed to build a linux x darwin cross compiler here, using the > osxcross tool. > > Indeed, clang++ stumbles on a bunch of issues. But then again, so > does clang in C-mode. If you are interested in fixing clang warnings I can submit some patches as I tend to build gdb with clang on FreeBSD. It gets really unhappy about unused functions from the VEC() generators which adds quite a bit of noise, but some of the things it finds are actual bugs (though probably harmless ones). -- John Baldwin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-21 15:18 ` John Baldwin @ 2016-04-21 16:41 ` Pedro Alves 0 siblings, 0 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-21 16:41 UTC (permalink / raw) To: John Baldwin, gdb-patches; +Cc: Walfred Tedeschi, Simon Marchi On 04/21/2016 02:42 AM, John Baldwin wrote: > If you are interested in fixing clang warnings I can submit some patches as > I tend to build gdb with clang on FreeBSD. It gets really unhappy about > unused functions from the VEC() generators which adds quite a bit of noise, I think that one was reported to clang before -- to make it stop complaining about unused functions defined in headers, and that they agreed that it was a clang bug. Maybe an option would be to disable the warning if compiling with clang. If it's not a too-ugly patch, maybe we could include it. > but some of the things it finds are actual bugs (though probably harmless > ones). Fixing actual bugs is always nice and welcome. [ Personally, I'd think it great if for each bug clang caught that gcc didn't, that a bug was filed against gcc. ] Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 14:18 ` Pedro Alves 2016-04-19 14:48 ` Eli Zaretskii [not found] ` <AC542571535E904D8E8ADAE745D60B19445B1C11@IRSMSX104.ger.corp.intel.com> @ 2016-04-19 15:47 ` Simon Marchi 2016-04-19 15:50 ` Pedro Alves 2016-04-20 22:27 ` Pedro Alves 3 siblings, 1 reply; 22+ messages in thread From: Simon Marchi @ 2016-04-19 15:47 UTC (permalink / raw) To: Pedro Alves, gdb-patches On 16-04-19 10:18 AM, Pedro Alves wrote: > On 04/19/2016 02:34 PM, Simon Marchi wrote: >> On 16-04-18 01:27 PM, Pedro Alves wrote: >>> It's been a long ride, but GDB now builds cleanly as a C++ program on >>> most supported systems. >>> >>> There are a few host-specific files that may be missing the occasional >>> cast, but for all I know, most of the codebase has been converted and >>> builds cleanly, with no undefined behavior and no hacks. >>> >>> It's time to try building GDB with a C++ compiler by default, which is >>> what the the following trivial patch does. >>> >>> Following the discussion on the gdb@ list, this flips the default on >>> all hosts, unconditionally. > >> Does that mean that all supported hosts have been tested to build in C++? > > "all" is a bit too wide. There are simply too many to tell: > > https://sourceware.org/gdb/wiki/Systems > > I don't know whether VAX or m68k BSD build cleanly, for instance. > I don't know whether they build cleanly in C-mode, either -- I > wouldn't be surprised if several of the listed systems on that > table didn't build today. > > It sort of goes back to what you'd call "supported host". If > nobody's actively caring about such hosts, then it's just > going to happen that changes elsewhere will accidentally break > them. > > But at least we know that x86-64 NetBSD and FreeBSD build and run > in C++ mode, which I think is sufficient proxy for all BSDs, in > the sense that if something else is needed it'll probably be a > couple malloc casts here and there in the corresponding $arch-nat.c > files. > > AFAIK, all GNU/Linux ports build cleanly. > > (Except maybe Xtensa, which may need your small cast patch on > my github. Is that one still needed?). > > MinGW (w64) builds and runs cleanly for me too. > > I think the ones pending confirmation are Solaris and QNX. > > If we do find some host does trip on some big problem, then we > can always flip it back to C by default. > > Given that the request for testing with --enable-build-with-cxx > was sent five months ago, and nobody reported breakage (nor success) > on Solaris/QNX, I think we need to bite the bullet and move forward. > > We won't know unless we try. > > WDYT? Yeah, it makes sense. I thought that you wanted to go gradually, flipping to C++ by default only the hosts we have tested, so that we see which ones are remaining (and test them). But I have absolutely no objection with flipping the switch globally :). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 15:47 ` Simon Marchi @ 2016-04-19 15:50 ` Pedro Alves 0 siblings, 0 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-19 15:50 UTC (permalink / raw) To: Simon Marchi, gdb-patches On 04/19/2016 04:47 PM, Simon Marchi wrote: > Yeah, it makes sense. I thought that you wanted to go gradually, > flipping to C++ by default only the hosts we have tested, so that > we see which ones are remaining (and test them). That was the original intention, but Joel convinced me otherwise: https://sourceware.org/ml/gdb/2016-04/msg00011.html ( I'm easy to convince :-) ) > But I have absolutely no objection with flipping the switch globally :). Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/1] Build GDB as a C++ program by default 2016-04-19 14:18 ` Pedro Alves ` (2 preceding siblings ...) 2016-04-19 15:47 ` Simon Marchi @ 2016-04-20 22:27 ` Pedro Alves 3 siblings, 0 replies; 22+ messages in thread From: Pedro Alves @ 2016-04-20 22:27 UTC (permalink / raw) To: Simon Marchi, gdb-patches On 04/19/2016 03:18 PM, Pedro Alves wrote: > I think the ones pending confirmation are Solaris and QNX. Meanwhile downthread Mac OS X came up. It had a C++ build error, but it's fixed now. > If we do find some host does trip on some big problem, then we > can always flip it back to C by default. > > Given that the request for testing with --enable-build-with-cxx > was sent five months ago, and nobody reported breakage (nor success) > on Solaris/QNX, I think we need to bite the bullet and move forward. Simon tried (thanks!) building on Solaris, but it failed in C-mode too, so I don't think it should block flipping the default. > > We won't know unless we try. I've pushed the patch in now. (With ChangeLog entry fixed.) Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2016-04-21 16:41 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-18 17:27 [PATCH 0/1] Build GDB as a C++ program by default Pedro Alves 2016-04-18 17:27 ` [PATCH 1/1] " Pedro Alves 2016-04-19 7:34 ` Yao Qi 2016-04-19 13:34 ` [PATCH 0/1] " Simon Marchi 2016-04-19 14:18 ` Pedro Alves 2016-04-19 14:48 ` Eli Zaretskii 2016-04-19 15:03 ` Pedro Alves 2016-04-19 15:23 ` Eli Zaretskii 2016-04-19 15:40 ` Pedro Alves 2016-04-19 15:59 ` Eli Zaretskii 2016-04-19 16:20 ` Pedro Alves 2016-04-19 16:31 ` Eli Zaretskii 2016-04-19 15:41 ` Simon Marchi 2016-04-19 16:32 ` Eli Zaretskii [not found] ` <AC542571535E904D8E8ADAE745D60B19445B1C11@IRSMSX104.ger.corp.intel.com> [not found] ` <5716425B.3050707@intel.com> [not found] ` <57164325.8020408@redhat.com> 2016-04-19 15:20 ` Walfred Tedeschi 2016-04-20 19:56 ` Pedro Alves 2016-04-20 22:16 ` Pedro Alves 2016-04-21 15:18 ` John Baldwin 2016-04-21 16:41 ` Pedro Alves 2016-04-19 15:47 ` Simon Marchi 2016-04-19 15:50 ` Pedro Alves 2016-04-20 22:27 ` Pedro Alves
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).