[PATCH 0/1] Build GDB as a C++ program by default

[PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

[PATCH 1/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 1/1] Build GDB as a C++ program by default

[Yao Qi]

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 (齐尧)

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Simon Marchi]

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++?

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Eli Zaretskii]

> 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.

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Walfred Tedeschi]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Eli Zaretskii]

> 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.

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Simon Marchi]

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?

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Simon Marchi]

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 :).

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Eli Zaretskii]

> 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.

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Eli Zaretskii]

> 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.

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Eli Zaretskii]

> 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.

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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), &reg_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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[John Baldwin]

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

Re: [PATCH 0/1] Build GDB as a C++ program by default

[Pedro Alves]

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