Re: [PATCH 00/36] Support building GDB as a C++ program

[Patrick Palka <patrick@parcs.ath.cx>]

On Fri, Feb 27, 2015 at 1:19 PM, Pedro Alves <palves@redhat.com> wrote:
> A quick status update on this series.  All patches but one
> up to the TRY_CATCH part are now pushed.  That is,
>
>     > [PATCH 01/36] Create libiberty/libiberty.m4, have GDB and GDBserver use it
>     > [PATCH 02/36] Add --enable-build-with-cxx configure switch
>     > [PATCH 03/36] C++ keyword cleanliness, mostly auto-generated
>     > [PATCH 04/36] Fix struct, union, and enum nesting in C++
>     > [PATCH 05/36] Fix redefinition errors in C++ mode
>     > [PATCH 06/36] record-btrace.c: Remove redefinitions
>     > [PATCH 07/36] Make array object extern
>     > [PATCH 08/36] elf-bfd.h: Wrap in extern "C".
>     > [PATCH 09/36] floatformat.h: Wrap in extern "C".
>     > [PATCH 10/36] Add extern "C" to declarations of C symbols
>     > [PATCH 11/36] Make functions and variables exported by the IPA be extern "C"
>     > [PATCH 12/36] proc-service, extern "C"
>     > [PATCH 13/36] target.h: Include infrun.h
>     > [PATCH 14/36] Do not do arithmetic on enum types
>     > [PATCH 15/36] Don't forward declare enum target_hw_bp_type
>     > [PATCH 16/36] x86 Linux/ptrace: fix offsetof usage in C++ mode
>     > [PATCH 17/36] mi/mi-cmd-stack.c|frame filters: print_values <-> ext_lang_frame_args
>     > [PATCH 18/36] Rename struct lzma_stream to avoid clash with system header
>     > [PATCH 19/36] Exported const objects
>     > [PATCH 21/36] opcodes/microblaze: Rename 'or', 'and', 'xor' to avoid C++ conflict
>     > [PATCH 22/36] Remove duplicate const
>     > [PATCH 23/36] gdbarch.h: include regcache.h
>     > [PATCH 24/36] breakpoint.h: move enum âprint_stop_actionâ
>     > [PATCH 25/36] python/python-internal.h: enum âext_lang_rcâ not defined
>     > [PATCH 26/36] Adjust self tests to cope with GDB built as a C++ program
>     > [PATCH 27/36] catch_command_errors: Remove 'mask' parameter
>     > [PATCH 28/36] Move exception_none to common code, and use it
>
> All the above are now pushed.
>
> I didn't push this one, as it introduces an aliasing violation:
>
>     > [PATCH 20/36] gdbserver/tracepoint: Add cast sockaddr_un/sockaddr cast
>
> These are still pending:
>
>     > [PATCH 29/36] Normalize TRY_CATCH exception handling block
>     > [PATCH 30/36] quit_force: Replace TRY_CATCH wrapper macros
>     > [PATCH 31/36] Split TRY_CATCH into TRY + CATCH
>     > [PATCH 32/36] TRY_CATCH -> TRY+CATCH+END_CATCH everywhere
>     > [PATCH 33/36] TRY_CATCH -> TRY+CATCH+END_CATCH, the manual conversions
>     > [PATCH 34/36] more making TRY/CATCH callers look more like real C++ try/catch blocks
>     > [PATCH 35/36] kill volatile struct gdb_exception
>     > [PATCH 36/36] Make TRY/CATCH use real C++ try/catch in C++ mode
>
> I don't have time right now to rebase this part, but I'd like
> to move ahead with it sometime soon.  If anyone has comments on
> this, now's the time to send them out.
>
>> Known problems:
>>
>> . Other hosts/native targets will naturally stumble on more
>>   host-specific code that needs converting, which I can't easily test.
>>   Help very much welcome!
>
> This is still true.  :-)
>
>>
>> . '--enable-targets=all' doesn't link yet in C++ mode.  This just more
>>   extern "C" problems.
>
> This is fixed, or will be, once the TRY_CATCH patches land,
> at least on x86_64 GNU/Linux.  It was handled with
> a couple bfd and opcodes patches.
>
>>
>> I wrote a second series a few months ago that built on an older
>> version of this one and fixes all the '-fpermissive' errors/warnings,
>> until GDB and GDBserver build cleanly with -Werror, on x86_64 Fedora.
>> It's naturally rotten in a few places by now, and in need of some
>> further cleaning up but it shouldn't be that far off.  You can find it
>> here:
>>
>>   https://github.com/palves/gdb/commits/palves/cxx-conversion-attempt-part-2-no-fpermissive
>>   git@github.com:palves/gdb.git palves/cxx-conversion-attempt-part-2-no-fpermissive
>
> A couple weeks ago I rebased this second part and cleaned it up
> substantially.  It's not fully ready, and now needs
> another rebase though...
>
> Thanks,
> Pedro Alves

Is GDB supposed to build yet with --enable-build-with-cxx? I am
currently getting a slew of errors and warnings when building GDB with
G++ 4.9.1.