Issue with Latest GDB on AIX with GCC-6.12

Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi,

The latest community gdb is not working with gcc 6.12, however, it
works expectedly fine with GCC-4.8.5 on AIX platform. Running any
non-existing command from the shell  is aborting the process.
Breaking at "throw_exception_cxx()" is giving us the following back
trace. I am copying backtrace for both 6.12 and 4.8.5 respectively:


Backtrace for gcc- 6.12:

Type "apropos word" to search for commands related to "word".
(gdb) kill

Breakpoint 3, _ZL19throw_exception_cxx13gdb_exception (exception=...)
at common/common-exceptions.c:289
289       do_cleanups (all_cleanups ());
(top-gdb) bt
#0  _ZL19throw_exception_cxx13gdb_exception (exception=...) at
common/common-exceptions.c:289
#1  0x0000000100073860 in _Z15throw_exception13gdb_exception
(exception=...) at common/common-exceptions.c:317
#2  0x0000000100073a38 in _ZL8throw_it13return_reason6errorsPKcPc
(reason=RETURN_ERROR, error=GENERIC_ERROR,
    fmt=0x100783730 <_GLOBAL__F_inferior_ptid+7616> "The program is
not being run.", ap=0xfffffffffffedb8 "\017ÿÿÿÿÿþ\216") at
common/common-exceptions.c:373
#3  0x0000000100073ab4 in _Z12throw_verror6errorsPKcPc (error=GENERIC_ERROR,
    fmt=0x100783730 <_GLOBAL__F_inferior_ptid+7616> "The program is
not being run.", ap=0xfffffffffffedb8 "\017ÿÿÿÿÿþ\216") at
common/common-exceptions.c:379
During symbol reading, Method has bad physname
_ZNKSt17integral_constantIbLb0EEcvbEv
.
During symbol reading, struct/union type gets multiply defined: struct
initializer_list.
#4  0x000000010001f918 in _Z6verrorPKcPc (string=0x100783730
<_GLOBAL__F_inferior_ptid+7616> "The program is not being run.",
    args=0xfffffffffffedb8 "\017ÿÿÿÿÿþ\216") at utils.c:475
#5  0x000000010001e0e0 in _Z5errorPKcz (fmt=0x100783730
<_GLOBAL__F_inferior_ptid+7616> "The program is not being run.") at
common/errors.c:43
#6  0x00000001001e906c in _ZL12kill_commandPci (arg=0x0, from_tty=1)
at infcmd.c:2578
#7  0x000000010011a4e0 in _ZL8do_cfuncP16cmd_list_elementPci
(c=0x11019edf0, args=0x0, from_tty=1) at cli/cli-decode.c:105
#8  0x000000010011f5a4 in _Z8cmd_funcP16cmd_list_elementPci
(cmd=0x11019edf0, args=0x0, from_tty=1) at cli/cli-decode.c:1913
#9  0x000000010007683c in _Z15execute_commandPci (p=0x1100e8ed4 "",
from_tty=1) at top.c:674
#10 0x000000010007e628 in _Z15command_handlerPc (command=0x1100e8ed0
"kill") at event-top.c:589
#11 0x000000010007ebdc in _Z20command_line_handlerPc (rl=0x1100e92b0
"") at event-top.c:779
#12 0x000000010007d994 in _ZL23gdb_rl_callback_handlerPc
(rl=0x1100e92b0 "") at event-top.c:213
#13 0x0000000100080f74 in rl_callback_read_char () at callback.c:220
#14 0x000000010007d79c in
_ZL42gdb_rl_callback_read_char_wrapper_noexceptv () at event-top.c:175
#15 0x000000010007d8a8 in _ZL33gdb_rl_callback_read_char_wrapperPv
(client_data=0x1100e8ef0) at event-top.c:192
#16 0x000000010007e2cc in _Z19stdin_event_handleriPv (error=0,
client_data=0x1100e8ef0) at event-top.c:517
#17 0x00000001003998c0 in _ZL17handle_file_eventP12file_handleri
(file_ptr=0x1101e5310, ready_mask=1) at event-loop.c:733
#18 0x0000000100399d54 in _ZL18gdb_wait_for_eventi (block=1) at event-loop.c:859
#19 0x0000000100398878 in _Z16gdb_do_one_eventv () at event-loop.c:347
#20 0x0000000100398910 in _Z16start_event_loopv () at event-loop.c:371
#21 0x0000000100001358 in _ZL21captured_command_loopPv (data=0x0) at main.c:325
#22 0x00000001003a306c in _Z12catch_errorsPFiPvES_Pc11return_mask
(func=@0x110082850: 0x1000012f8 <_ZL21captured_command_loopPv>,
func_args=0x0,
    errstring=0x10071b518 <_GLOBAL__F_interpreter_p+3608> "",
mask=RETURN_MASK_ALL) at exceptions.c:236
#23 0x0000000100002f90 in _ZL13captured_mainPv
(data=0xffffffffffff9c0) at main.c:1148
#24 0x0000000100002ffc in _Z8gdb_mainP18captured_main_args
(args=0xffffffffffff9c0) at main.c:1158
#25 0x0000000100000748 in main (argc=1, argv=0xffffffffffffa70) at gdb.c:32




Backtrace for gcc-4.8.5:


Type "apropos word" to search for commands related to "word".
(gdb) kill

Breakpoint 3, _ZL19throw_exception_cxx13gdb_exception (exception=...)
at common/common-exceptions.c:289
289     common/common-exceptions.c: A file or directory in the path
name does not exist..
(top-gdb) bt
#0  _ZL19throw_exception_cxx13gdb_exception (exception=...) at
common/common-exceptions.c:289
#1  0x000000010005b848 in _Z15throw_exception13gdb_exception
(exception=...) at common/common-exceptions.c:317
#2  0x000000010005ba3c in _ZL8throw_it13return_reason6errorsPKcPc
(reason=RETURN_ERROR, error=GENERIC_ERROR,
    fmt=0x100817628 <type_print_raw_options+147320> "The program is
not being run.", ap=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at
common/common-exceptions.c:373
#3  0x000000010005babc in _Z12throw_verror6errorsPKcPc (error=GENERIC_ERROR,
    fmt=0x100817628 <type_print_raw_options+147320> "The program is
not being run.", ap=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at
common/common-exceptions.c:379
During symbol reading, Method has bad physname
_ZNKSt17integral_constantIbLb0EEcvbEv
.
During symbol reading, struct/union type gets multiply defined: struct
initializer_list.
#4  0x000000010005f07c in _Z6verrorPKcPc (string=0x100817628
<type_print_raw_options+147320> "The program is not being run.",
    args=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at utils.c:475
#5  0x0000000100085af0 in _Z5errorPKcz (fmt=0x100817628
<type_print_raw_options+147320> "The program is not being run.") at
common/errors.c:43
#6  0x00000001001e1938 in _ZL12kill_commandPci (arg=0x0, from_tty=1)
at infcmd.c:2578
#7  0x0000000100134200 in _ZL8do_cfuncP16cmd_list_elementPci
(c=0x1102442d0, args=0x0, from_tty=1) at cli/cli-decode.c:105
#8  0x0000000100139464 in _Z8cmd_funcP16cmd_list_elementPci
(cmd=0x1102442d0, args=0x0, from_tty=1) at cli/cli-decode.c:1913
#9  0x00000001000aca90 in _Z15execute_commandPci (p=0x11018f234 "",
from_tty=1) at top.c:674
#10 0x00000001000b4cb4 in _Z15command_handlerPc (command=0x11018f230
"kill") at event-top.c:590
#11 0x00000001000b5288 in _Z20command_line_handlerPc (rl=0x11018f610
"") at event-top.c:780
#12 0x00000001000b4004 in _ZL23gdb_rl_callback_handlerPc
(rl=0x11018f610 "") at event-top.c:213
#13 0x00000001000b7658 in rl_callback_read_char () at callback.c:220
#14 0x00000001000b3dc0 in
_ZL42gdb_rl_callback_read_char_wrapper_noexceptv () at event-top.c:175
#15 0x00000001000b3f18 in _ZL33gdb_rl_callback_read_char_wrapperPv
(client_data=0x11018f250) at event-top.c:192
#16 0x00000001000b4950 in _Z19stdin_event_handleriPv (error=0,
client_data=0x11018f250) at event-top.c:518
During symbol reading, Unexpected storage class: 111.
#17 0x000000010045728c in _ZL17handle_file_eventP12file_handleri
(file_ptr=0x11028a7b0, ready_mask=1) at event-loop.c:733
#18 0x0000000100457774 in _ZL18gdb_wait_for_eventi (block=1) at event-loop.c:859
#19 0x00000001004560bc in _Z16gdb_do_one_eventv () at event-loop.c:347
#20 0x0000000100456154 in _Z16start_event_loopv () at event-loop.c:371
#21 0x00000001000014e4 in _ZL21captured_command_loopPv (data=0x0) at main.c:325
#22 0x0000000100221c1c in _Z12catch_errorsPFiPvES_Pc11return_mask
(func=@0x11012d038: 0x100001480 <_ZL21captured_command_loopPv>,
func_args=0x0,
    errstring=0x1008574e0 <target_name+245360> "",
mask=RETURN_MASK_ALL) at exceptions.c:236
#23 0x00000001000032f8 in _ZL13captured_mainPv
(data=0xffffffffffffa20) at main.c:1148
#24 0x0000000100003364 in _Z8gdb_mainP18captured_main_args
(args=0xffffffffffffa20) at main.c:1158
#25 0x000000010000074c in main (argc=1, argv=0xffffffffffffad0) at gdb.c:32
(top-gdb) c
Continuing.

Breakpoint 3, _ZL19throw_exception_cxx13gdb_exception (exception=...)
at common/common-exceptions.c:289
289     in common/common-exceptions.c
(top-gdb) c
Continuing.
The program is not being run.


We are trying some sample programs using readline library to propagate
exceptions through callback handler just to check if we face any issue
there. We are still working on it, can't say anything for sure.
It seems like this is a issue regarding  exception propagation as
eventually std::terminate() is getting called. Which also suggests
that some how exceptions thrown is not getting handled properly.

-- -- -- --
Nitish K Mishra

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 01/25/2017 10:54 AM, Nitish Kumar Mishra wrote:
> Hi,
> 
> The latest community gdb is not working with gcc 6.12, however, it
> works expectedly fine with GCC-4.8.5 on AIX platform.

What is gcc 6.12 ?

> #12 0x000000010007d994 in _ZL23gdb_rl_callback_handlerPc
> (rl=0x1100e92b0 "") at event-top.c:213

I only saw C++ frames up to here, and the exception should
be caught here.  I don't immediately see why that wouldn't
be working, though maybe it's the "noexcept"?  If you remove
that, does it fix it?  Maybe we need a level of indirection
here too, like in gdb_rl_callback_read_char_wrapper_noexcept
/ gdb_rl_callback_read_char_wrapper.


> We are trying some sample programs using readline library to propagate
> exceptions through callback handler just to check if we face any issue
> there. We are still working on it, can't say anything for sure.

Right, it's known that C++ exceptions can't cross readline (unless
built with -fexceptions)  See log of commits:

 89525768cd08 ("Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH)
 2693a26216c3 ("Fix longjmp across readline w/ --enable-sjlj-exceptions toolchains")

But it looks like the mechanism to work around that isn't working for you.

> It seems like this is a issue regarding  exception propagation as
> eventually std::terminate() is getting called. Which also suggests
> that some how exceptions thrown is not getting handled properly.

Yes.

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 01/25/2017 11:12 AM, Pedro Alves wrote:
> On 01/25/2017 10:54 AM, Nitish Kumar Mishra wrote:
>> Hi,
>>
>> The latest community gdb is not working with gcc 6.12, however, it
>> works expectedly fine with GCC-4.8.5 on AIX platform.
> 
> What is gcc 6.12 ?
> 
>> #12 0x000000010007d994 in _ZL23gdb_rl_callback_handlerPc
>> (rl=0x1100e92b0 "") at event-top.c:213
> 
> I only saw C++ frames up to here, and the exception should
> be caught here.  I don't immediately see why that wouldn't
> be working, though maybe it's the "noexcept"?  If you remove
> that, does it fix it?  Maybe we need a level of indirection
> here too, like in gdb_rl_callback_read_char_wrapper_noexcept
> / gdb_rl_callback_read_char_wrapper.

I could reproduce this on gcc119 on the compile farm (AIX 7.2),
which has GCC 6.1.  I tried the workaround suggested above, but
that didn't work.

TBC, it's perfectly valid for a noexpect function to
try/catch inside as long as no exception escapes out, but,
compiler bugs are not unheard-of.

I also tried replacing the TRY/CATCH macros with try/catch(...)
thinking that it could be something with broken type info,
and the runtime somehow not figuring out that that catch
should really catch the exception.  Same thing, doesn't work
for me.

So I'm out of ideas.  It looks like a toolchain/runtime bug
to me.

TBC, I'm not going to be looking at this further.  It's
very uncomfortable for me to use that machine --- I get a
bit too high latency, and emacs doesn't work.  I even tried
to survive with vi, but then DEL/BS didn't work for me.  :-P

Here's what I had tried.

From 968f6a4e0744f06f011ab585930dbd4d9cf5b8d6 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Wed, 25 Jan 2017 13:15:04 +0000
Subject: [PATCH] AIX

---
 gdb/event-top.c | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/gdb/event-top.c b/gdb/event-top.c
index ae4f704..789d419 100644
--- a/gdb/event-top.c
+++ b/gdb/event-top.c
@@ -196,27 +196,38 @@ gdb_rl_callback_read_char_wrapper (gdb_client_data client_data)
     throw_exception (gdb_expt);
 }
 
-/* GDB's readline callback handler.  Calls the current INPUT_HANDLER,
-   and propagates GDB exceptions/errors thrown from INPUT_HANDLER back
-   across readline.  See gdb_rl_callback_read_char_wrapper.  This must
-   be noexcept in order to avoid problems with mixing sjlj and
-   (sjlj-based) C++ exceptions.  */
+/* Calls the current INPUT_HANDLER, and returns any GDB
+   exceptions/errors thrown from INPUT_HANDLER as a normal return.
+   See gdb_rl_callback_handler.  */
 
-static void
-gdb_rl_callback_handler (char *rl) noexcept
+static struct gdb_exception
+input_handler_wrapper (char *rl)
 {
   struct gdb_exception gdb_rl_expt = exception_none;
   struct ui *ui = current_ui;
 
-  TRY
+  try
     {
       ui->input_handler (rl);
     }
-  CATCH (ex, RETURN_MASK_ALL)
+  catch (...)
     {
-      gdb_rl_expt = ex;
     }
-  END_CATCH
+
+  return gdb_rl_expt;
+}
+
+/* GDB's readline callback handler.  Calls the current INPUT_HANDLER,
+   and propagates GDB exceptions/errors thrown from INPUT_HANDLER back
+   across readline.  See gdb_rl_callback_read_char_wrapper.  This must
+   be noexcept in order to avoid problems with mixing sjlj and
+   (sjlj-based) C++ exceptions.  */
+
+static void
+gdb_rl_callback_handler (char *rl) noexcept
+{
+  struct gdb_exception gdb_rl_expt
+    = input_handler_wrapper (rl);
 
   /* If we caught a GDB exception, longjmp out of the readline
      callback.  There's no other way for the callback to signal to
-- 
2.5.5

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 01/25/2017 01:52 PM, Pedro Alves wrote:
> On 01/25/2017 11:12 AM, Pedro Alves wrote:
>> On 01/25/2017 10:54 AM, Nitish Kumar Mishra wrote:
>>> Hi,
>>>
>>> The latest community gdb is not working with gcc 6.12, however, it
>>> works expectedly fine with GCC-4.8.5 on AIX platform.
>>
>> What is gcc 6.12 ?
>>
>>> #12 0x000000010007d994 in _ZL23gdb_rl_callback_handlerPc
>>> (rl=0x1100e92b0 "") at event-top.c:213
>>
>> I only saw C++ frames up to here, and the exception should
>> be caught here.  I don't immediately see why that wouldn't
>> be working, though maybe it's the "noexcept"?  If you remove
>> that, does it fix it?  Maybe we need a level of indirection
>> here too, like in gdb_rl_callback_read_char_wrapper_noexcept
>> / gdb_rl_callback_read_char_wrapper.
> 
> I could reproduce this on gcc119 on the compile farm (AIX 7.2),
> which has GCC 6.1.  I tried the workaround suggested above, but
> that didn't work.
> 
> TBC, it's perfectly valid for a noexpect function to
> try/catch inside as long as no exception escapes out, but,
> compiler bugs are not unheard-of.
> 
> I also tried replacing the TRY/CATCH macros with try/catch(...)
> thinking that it could be something with broken type info,
> and the runtime somehow not figuring out that that catch
> should really catch the exception.  Same thing, doesn't work
> for me.
> 
> So I'm out of ideas.  It looks like a toolchain/runtime bug
> to me.

Sounds like a manifestation of:

 Bug 60939 - AIX: exceptions not caught when calling function via pointer 
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939

since ui->input_handler is a function pointer here:

static void
gdb_rl_callback_handler (char *rl) noexcept
{
  struct gdb_exception gdb_rl_expt = exception_none;
  struct ui *ui = current_ui;

  TRY
    {
      ui->input_handler (rl);
    }
  CATCH (ex, RETURN_MASK_ALL)
    {
      gdb_rl_expt = ex;
    }
  END_CATCH

> 
> TBC, I'm not going to be looking at this further.  It's
> very uncomfortable for me to use that machine --- I get a
> bit too high latency, and emacs doesn't work.  I even tried
> to survive with vi, but then DEL/BS didn't work for me.  :-P

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[Yao Qi]

On 17-01-25 13:52:49, Pedro Alves wrote:
> 
> So I'm out of ideas.  It looks like a toolchain/runtime bug
> to me.
> 

Hi Pedro,
GDB on AIX (at least gcc119) is broken since Nov 2016 at least.
https://sourceware.org/ml/gdb/2016-11/msg00023.html

I tried to debug libgcc on exception unwinding (in assembly!).  I
have a vague memory that unwinder stops unwinding after one or two
frames.  I suspect either gcc generate wrong .eh_frame or libgcc
is buggy.  That is where I stopped.

-- 
Yao (齐尧)

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 01/25/2017 02:37 PM, Yao Qi wrote:
> On 17-01-25 13:52:49, Pedro Alves wrote:
>>
>> So I'm out of ideas.  It looks like a toolchain/runtime bug
>> to me.
>>
> 
> Hi Pedro,
> GDB on AIX (at least gcc119) is broken since Nov 2016 at least.
> https://sourceware.org/ml/gdb/2016-11/msg00023.html
> 
> I tried to debug libgcc on exception unwinding (in assembly!).  I
> have a vague memory that unwinder stops unwinding after one or two
> frames.  I suspect either gcc generate wrong .eh_frame or libgcc
> is buggy.  That is where I stopped.
> 

Ah, I recalled some previous discussion, but somehow
got confused and thought that it had been fixed at the time,
and then thought this could have been a regression due to
the more recent noexcept addition.  Oh well.

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

>>>>> Pedro Alves writes:

> Sounds like a manifestation of:
>
>  Bug 60939 - AIX: exceptions not caught when calling function via pointer
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
>
> since ui->input_handler is a function pointer here:
>
> static void
> gdb_rl_callback_handler (char *rl) noexcept
> {
>   struct gdb_exception gdb_rl_expt = exception_none;
>   struct ui *ui = current_ui;
>
>   TRY
>     {
>       ui->input_handler (rl);
>     }
>   CATCH (ex, RETURN_MASK_ALL)
>     {
>       gdb_rl_expt = ex;
>     }
>   END_CATCH

If the problem is throwing an exception through a function called via
pointer, then the solution should be to follow the suggestion in
comment #8 and add an appropriate incantation of

-Wl,-bkeepfile:

to the link step for GDB, something like

gdb/config/powerpc/aix.mh
MH_LDFLAGS = -Wl,-bkeepfile:event-top.o

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Sat, Jan 28, 2017 at 6:56 PM, David Edelsohn <dje.gcc@gmail.com> wrote:

> If the problem is throwing an exception through a function called via
> pointer, then the solution should be to follow the suggestion in
> comment #8 and add an appropriate incantation of
>
> -Wl,-bkeepfile:
>
> to the link step for GDB, something like
>
> gdb/config/powerpc/aix.mh
> MH_LDFLAGS = -Wl,-bkeepfile:event-top.o

-bkeepfile for the obvious candidates does not fix the problem.  And
-bexpfull fails to links.

FYI, there is a ramdisk filesystem mounted as /scratch that greatly
speeds up Git checkout and builds, although the underlying filesystem
obviously is transient and should not be used for persistent files.  I
am waiting for an Emacs build without the incorrect dependency.  For
BS/DEL, at worst you can remap it with stty erase ^? .

Note that std::terminate() is called specifically because there was an
unwind failure and no handler was found in eh_throw.cc in libsupc++
(part of libstdc++).

Is this code trying to propagate an exception through a signal
handler, in which case GCC MD_FALLBACK_FRAME_STATE_FOR needs to be
tweaked to find more AIX kernel signal handler signatures.

- David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 01/29/2017 01:11 AM, David Edelsohn wrote:

> Note that std::terminate() is called specifically because there was an
> unwind failure and no handler was found in eh_throw.cc in libsupc++
> (part of libstdc++).

Right, that's what makes it look like either an runtime unwinder,
or unwind info bug.

> Is this code trying to propagate an exception through a signal
> handler, in which case GCC MD_FALLBACK_FRAME_STATE_FOR needs to be
> tweaked to find more AIX kernel signal handler signatures.

Nope, it's just normal C++ frames all the way from the throw to
the "catch" that should catch the exception.

(GDB stopped throwing from signal handlers before we flipped
the C++ switch, with:
 [PATCH 00/30] Stop throwing exceptions from signal handlers
 https://sourceware.org/ml/gdb-patches/2016-03/msg00351.html
)

I'd suggest progressively hacking in "catches" to frames
closer to the throw in question helps identify the frame that
can't be unwound.  Like, sprinkling in a few:

try
  {
    ...
  }
catch (...)
  {
    printf ("%s:%d: got here\n", __FILE__, __LINE__)
    throw;
  }

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi All !

As Pedro suggested to have some print statements in "catches" blocks
to identify the frame that can't be unwound, I did try that.
Most of the functions didn't have the try-catch except,
gdb_rl_callback_handler ()
gdb_rl_callback_read_char_wrapper ()
gdb_rl_callback_read_char_wrapper_noexcept (),
where I put the print statements but during execution none of these
print statements get executed.

In the function:
static void
 gdb_rl_callback_handler (char *rl) noexcept
 {
   struct gdb_exception gdb_rl_expt = exception_none;
   struct ui *ui = current_ui;

   TRY
     {
       ui->input_handler (rl);
     }
   CATCH (ex, RETURN_MASK_ALL)
     {
       gdb_rl_expt = ex;
     }
   END_CATCH

I tried calling command_line_handler () without function pointer (as
it seems that it is a known issue with AIX and function pointers), but
again it didn't help.

Thanks,
Nitish


On Tue, Jan 31, 2017 at 6:38 PM, Pedro Alves <palves@redhat.com> wrote:
> On 01/29/2017 01:11 AM, David Edelsohn wrote:
>
>> Note that std::terminate() is called specifically because there was an
>> unwind failure and no handler was found in eh_throw.cc in libsupc++
>> (part of libstdc++).
>
> Right, that's what makes it look like either an runtime unwinder,
> or unwind info bug.
>
>> Is this code trying to propagate an exception through a signal
>> handler, in which case GCC MD_FALLBACK_FRAME_STATE_FOR needs to be
>> tweaked to find more AIX kernel signal handler signatures.
>
> Nope, it's just normal C++ frames all the way from the throw to
> the "catch" that should catch the exception.
>
> (GDB stopped throwing from signal handlers before we flipped
> the C++ switch, with:
>  [PATCH 00/30] Stop throwing exceptions from signal handlers
>  https://sourceware.org/ml/gdb-patches/2016-03/msg00351.html
> )
>
> I'd suggest progressively hacking in "catches" to frames
> closer to the throw in question helps identify the frame that
> can't be unwound.  Like, sprinkling in a few:
>
> try
>   {
>     ...
>   }
> catch (...)
>   {
>     printf ("%s:%d: got here\n", __FILE__, __LINE__)
>     throw;
>   }
>
> Thanks,
> Pedro Alves
>

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 02/07/2017 08:05 AM, Nitish Kumar Mishra wrote:
> Hi All !
> 
> As Pedro suggested to have some print statements in "catches" blocks
> to identify the frame that can't be unwound, I did try that.
> Most of the functions didn't have the try-catch except,
> gdb_rl_callback_handler ()
> gdb_rl_callback_read_char_wrapper ()
> gdb_rl_callback_read_char_wrapper_noexcept (),
> where I put the print statements but during execution none of these
> print statements get executed.

Actually, I suggested to _add_ more try/catch blocks.

Taking the backtrace from your original post:

> Breakpoint 3, _ZL19throw_exception_cxx13gdb_exception (exception=...)
> at common/common-exceptions.c:289
> 289     common/common-exceptions.c: A file or directory in the path
> name does not exist..
> (top-gdb) bt
> #0  _ZL19throw_exception_cxx13gdb_exception (exception=...) at
> common/common-exceptions.c:289
> #1  0x000000010005b848 in _Z15throw_exception13gdb_exception
> (exception=...) at common/common-exceptions.c:317
> #2  0x000000010005ba3c in _ZL8throw_it13return_reason6errorsPKcPc
> (reason=RETURN_ERROR, error=GENERIC_ERROR,
>     fmt=0x100817628 <type_print_raw_options+147320> "The program is
> not being run.", ap=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at
> common/common-exceptions.c:373
> #3  0x000000010005babc in _Z12throw_verror6errorsPKcPc (error=GENERIC_ERROR,
>     fmt=0x100817628 <type_print_raw_options+147320> "The program is
> not being run.", ap=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at
> common/common-exceptions.c:379
> During symbol reading, Method has bad physname
> _ZNKSt17integral_constantIbLb0EEcvbEv
> .
> During symbol reading, struct/union type gets multiply defined: struct
> initializer_list.
> #4  0x000000010005f07c in _Z6verrorPKcPc (string=0x100817628
> <type_print_raw_options+147320> "The program is not being run.",
>     args=0xfffffffffffee18 "\017ÿÿÿÿÿþX") at utils.c:475
> #5  0x0000000100085af0 in _Z5errorPKcz (fmt=0x100817628
> <type_print_raw_options+147320> "The program is not being run.") at
> common/errors.c:43
> #6  0x00000001001e1938 in _ZL12kill_commandPci (arg=0x0, from_tty=1)
> at infcmd.c:2578
> #7  0x0000000100134200 in _ZL8do_cfuncP16cmd_list_elementPci
> (c=0x1102442d0, args=0x0, from_tty=1) at cli/cli-decode.c:105
> #8  0x0000000100139464 in _Z8cmd_funcP16cmd_list_elementPci
> (cmd=0x1102442d0, args=0x0, from_tty=1) at cli/cli-decode.c:1913
> #9  0x00000001000aca90 in _Z15execute_commandPci (p=0x11018f234 "",
> from_tty=1) at top.c:674
> #10 0x00000001000b4cb4 in _Z15command_handlerPc (command=0x11018f230
> "kill") at event-top.c:590
> #11 0x00000001000b5288 in _Z20command_line_handlerPc (rl=0x11018f610
> "") at event-top.c:780
> #12 0x00000001000b4004 in _ZL23gdb_rl_callback_handlerPc
> (rl=0x11018f610 "") at event-top.c:213

We know the exception should be caught in frame #12.  But somehow,
the run time unwinder doesn't realize this, and calls std::terminate,
meaning it can't find a matching catch for the thrown exception.
This suggests that the unwinder can't unwind some frame from the
set of frames #0 to frame #12.  The suggestion was to _add_ try/catch 
blocks in some frames between #0 - #12, and do some printing in the
added catch blocks.  For example, wrap frame #6, i.e., the
kill_command function, by renaming it to kill_command_org
and add:

static void
kill_command (char *arg, int from_tty)
{
   try
     {
        kill_command_org (arg, from_tty);
     }
   catch (...)
     {
        printf ("%s:%d: got here\n", __FILE__, __LINE__)
        throw;        
     }
}

This will cut in half the potential problematic frames.

Alternatively, someone could debug the unwinder itself (libgcc?),
which should also reveal why didn't the unwinder find that there's
a "catch" in frame #12 in the original backtrace that catches
the thrown exception.

I'm assuming that we've run into a corner case, and that GDB has
thrown other C++ exceptions that were caught successfully before
we get to this problematic exception, during gdb startup.
I.e., I don't recall whether I confirmed that a simple hello-word that
does try{throw 1;}/catch(...){} manages to catch the exception
correctly.  If it doesn't then there's some fundamental problem
with C++ exceptions in this compiler build.

Speaking of compilers, we know that building gdb with gcc 4.8.5
doesn't run into this.  Do we know that changed?  Did, for example,
AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5
and 6.1?  Might also be useful to try to build gdb with current
gcc trunk / gcc 7.

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Tue, Feb 7, 2017 at 5:30 AM, Pedro Alves <palves@redhat.com> wrote:

> Speaking of compilers, we know that building gdb with gcc 4.8.5
> doesn't run into this.  Do we know that changed?  Did, for example,
> AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5
> and 6.1?  Might also be useful to try to build gdb with current
> gcc trunk / gcc 7.

I cannot tell if some have reported that GCC 4.8.5 works correctly or not.

I believe that GDB links libstdc++ statically.  Does it work if linked
dynamically?

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 02/07/2017 01:44 PM, David Edelsohn wrote:
> On Tue, Feb 7, 2017 at 5:30 AM, Pedro Alves <palves@redhat.com> wrote:
> 
>> Speaking of compilers, we know that building gdb with gcc 4.8.5
>> doesn't run into this.  Do we know that changed?  Did, for example,
>> AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5
>> and 6.1?  Might also be useful to try to build gdb with current
>> gcc trunk / gcc 7.
> 
> I cannot tell if some have reported that GCC 4.8.5 works correctly or not.

The OP said it works fine on GCC 4.8.5 here:

 https://sourceware.org/ml/gdb/2017-01/msg00044.html

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Tue, Feb 7, 2017 at 8:56 AM, Pedro Alves <palves@redhat.com> wrote:
> On 02/07/2017 01:44 PM, David Edelsohn wrote:
>> On Tue, Feb 7, 2017 at 5:30 AM, Pedro Alves <palves@redhat.com> wrote:
>>
>>> Speaking of compilers, we know that building gdb with gcc 4.8.5
>>> doesn't run into this.  Do we know that changed?  Did, for example,
>>> AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5
>>> and 6.1?  Might also be useful to try to build gdb with current
>>> gcc trunk / gcc 7.
>>
>> I cannot tell if some have reported that GCC 4.8.5 works correctly or not.
>
> The OP said it works fine on GCC 4.8.5 here:
>
>  https://sourceware.org/ml/gdb/2017-01/msg00044.html

Yes, but I thought that there was a later comment that GCC 4.8 also
showed problems.

There was a change in the encoding of data for AIX, but not a change
to the basic EH frames or handlers.  AIX did not change EH mechanisms
and never used SJLJ -- at least not for a very long time.

One test is to use shared libraries to link GDB.

Another possible contribution is the AIX address space.  There have
been reports in the past of EH frames not sorted correctly and libgcc
EH not finding exception handlers because it terminated the search
early.

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi All,
>> Yes, but I thought that there was a later comment that GCC 4.8 also
showed problems.
GCC-4.8.5 is working correctly, I have pasted the OP in earlier mail.

>>We know the exception should be caught in frame #12.  But somehow,
the run time unwinder doesn't realize this, and calls std::terminate,
meaning it can't find a matching catch for the thrown exception.
This suggests that the unwinder can't unwind some frame from the
set of frames #0 to frame #12.  The suggestion was to _add_ try/catch
blocks in some frames between #0 - #12, and do some printing in the
added catch blocks.  For example, wrap frame #6, i.e., the
kill_command function, by renaming it to kill_command_org
and add:

I tried adding try/catch block earlier in throw_it and
throw_exception_cxx functions
but got no significant results.
I had tried adding try catch block in these functions:
kill_command
command_handler
command_line_handler
execute_command
throw_it
throw_exception_cxx,
but no progress. Output is exactly same as we got earlier (Other than
extra frames for new
try catch functions). None of the print statements in catch blocks for
above functions worked.


Thanks and Regards,
Nitish


On Tue, Feb 7, 2017 at 7:45 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Tue, Feb 7, 2017 at 8:56 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 02/07/2017 01:44 PM, David Edelsohn wrote:
>>> On Tue, Feb 7, 2017 at 5:30 AM, Pedro Alves <palves@redhat.com> wrote:
>>>
>>>> Speaking of compilers, we know that building gdb with gcc 4.8.5
>>>> doesn't run into this.  Do we know that changed?  Did, for example,
>>>> AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5
>>>> and 6.1?  Might also be useful to try to build gdb with current
>>>> gcc trunk / gcc 7.
>>>
>>> I cannot tell if some have reported that GCC 4.8.5 works correctly or not.
>>
>> The OP said it works fine on GCC 4.8.5 here:
>>
>>  https://sourceware.org/ml/gdb/2017-01/msg00044.html
>
> Yes, but I thought that there was a later comment that GCC 4.8 also
> showed problems.
>
> There was a change in the encoding of data for AIX, but not a change
> to the basic EH frames or handlers.  AIX did not change EH mechanisms
> and never used SJLJ -- at least not for a very long time.
>
> One test is to use shared libraries to link GDB.
>
> Another possible contribution is the AIX address space.  There have
> been reports in the past of EH frames not sorted correctly and libgcc
> EH not finding exception handlers because it terminated the search
> early.
>
> Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi All,

>>I'm assuming that we've run into a corner case, and that GDB has
thrown other C++ exceptions that were caught successfully before
we get to this problematic exception, during gdb startup.
I.e., I don't recall whether I confirmed that a simple hello-word that
does try{throw 1;}/catch(...){} manages to catch the exception
correctly.  If it doesn't then there's some fundamental problem
with C++ exceptions in this compiler build.

We tried simple try/catch program using readline library with GCC-6.1
and it is working perfectly all right.

Looking forward to work on this suggestion:
>> Alternatively, someone could debug the unwinder itself (libgcc?),
which should also reveal why didn't the unwinder find that there's
a "catch" in frame #12 in the original backtrace that catches
the thrown exception.


Thanks and Regards,
Nitish

On Wed, Feb 8, 2017 at 11:46 AM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi All,
>>> Yes, but I thought that there was a later comment that GCC 4.8 also
> showed problems.
> GCC-4.8.5 is working correctly, I have pasted the OP in earlier mail.
>
>>>We know the exception should be caught in frame #12.  But somehow,
> the run time unwinder doesn't realize this, and calls std::terminate,
> meaning it can't find a matching catch for the thrown exception.
> This suggests that the unwinder can't unwind some frame from the
> set of frames #0 to frame #12.  The suggestion was to _add_ try/catch
> blocks in some frames between #0 - #12, and do some printing in the
> added catch blocks.  For example, wrap frame #6, i.e., the
> kill_command function, by renaming it to kill_command_org
> and add:
>
> I tried adding try/catch block earlier in throw_it and
> throw_exception_cxx functions
> but got no significant results.
> I had tried adding try catch block in these functions:
> kill_command
> command_handler
> command_line_handler
> execute_command
> throw_it
> throw_exception_cxx,
> but no progress. Output is exactly same as we got earlier (Other than
> extra frames for new
> try catch functions). None of the print statements in catch blocks for
> above functions worked.
>
>
> Thanks and Regards,
> Nitish
>
>
> On Tue, Feb 7, 2017 at 7:45 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> On Tue, Feb 7, 2017 at 8:56 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 02/07/2017 01:44 PM, David Edelsohn wrote:
>>>> On Tue, Feb 7, 2017 at 5:30 AM, Pedro Alves <palves@redhat.com> wrote:
>>>>
>>>>> Speaking of compilers, we know that building gdb with gcc 4.8.5
>>>>> doesn't run into this.  Do we know that changed?  Did, for example,
>>>>> AIX switch from sjlj to dwarf-based exceptions between gcc 4.8.5
>>>>> and 6.1?  Might also be useful to try to build gdb with current
>>>>> gcc trunk / gcc 7.
>>>>
>>>> I cannot tell if some have reported that GCC 4.8.5 works correctly or not.
>>>
>>> The OP said it works fine on GCC 4.8.5 here:
>>>
>>>  https://sourceware.org/ml/gdb/2017-01/msg00044.html
>>
>> Yes, but I thought that there was a later comment that GCC 4.8 also
>> showed problems.
>>
>> There was a change in the encoding of data for AIX, but not a change
>> to the basic EH frames or handlers.  AIX did not change EH mechanisms
>> and never used SJLJ -- at least not for a very long time.
>>
>> One test is to use shared libraries to link GDB.
>>
>> Another possible contribution is the AIX address space.  There have
>> been reports in the past of EH frames not sorted correctly and libgcc
>> EH not finding exception handlers because it terminated the search
>> early.
>>
>> Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 02/08/2017 06:16 AM, Nitish Kumar Mishra wrote:

> I tried adding try/catch block earlier in throw_it and
> throw_exception_cxx functions
> but got no significant results.
> I had tried adding try catch block in these functions:
> kill_command
> command_handler
> command_line_handler
> execute_command
> throw_it
> throw_exception_cxx,
> but no progress. Output is exactly same as we got earlier (Other than
> extra frames for new
> try catch functions). None of the print statements in catch blocks for
> above functions worked.

Eh, it sounds like _no_ exception catching works then?  I just
confirmed now that at least on GNU/Linux, GDB does not throw any 
exception internally during startup.  This backtrace in question may
well not be special at all, and may be that _all_ exception catching
is broken.  I'd try experimenting with simple things like:

try
{
  throw 1;
}
catch (...)
{
   printf (....);
}

right at the start of gdb's main().  Not in a separately
compiled test program, but really inside gdb, to avoid
differences in how gdb vs the test program is built.

It could also be that this is only triggered due to
GDB's binary size, hence not triggered in a small program -- I
recall that there was some trouble with the size of some sessions
and the linker in the AIX 7.1 box couldn't link gdb, or something
like that?  Maybe that's not fully/correctly sorted out.

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Wed, Feb 8, 2017 at 7:06 AM, Pedro Alves <palves@redhat.com> wrote:
> On 02/08/2017 06:16 AM, Nitish Kumar Mishra wrote:
>
>> I tried adding try/catch block earlier in throw_it and
>> throw_exception_cxx functions
>> but got no significant results.
>> I had tried adding try catch block in these functions:
>> kill_command
>> command_handler
>> command_line_handler
>> execute_command
>> throw_it
>> throw_exception_cxx,
>> but no progress. Output is exactly same as we got earlier (Other than
>> extra frames for new
>> try catch functions). None of the print statements in catch blocks for
>> above functions worked.
>
> Eh, it sounds like _no_ exception catching works then?  I just
> confirmed now that at least on GNU/Linux, GDB does not throw any
> exception internally during startup.  This backtrace in question may
> well not be special at all, and may be that _all_ exception catching
> is broken.  I'd try experimenting with simple things like:
>
> try
> {
>   throw 1;
> }
> catch (...)
> {
>    printf (....);
> }
>
> right at the start of gdb's main().  Not in a separately
> compiled test program, but really inside gdb, to avoid
> differences in how gdb vs the test program is built.
>
> It could also be that this is only triggered due to
> GDB's binary size, hence not triggered in a small program -- I
> recall that there was some trouble with the size of some sessions
> and the linker in the AIX 7.1 box couldn't link gdb, or something
> like that?  Maybe that's not fully/correctly sorted out.

Nitish,

GDB is linked with static libstdc++ and libgcc.

-static-libstdc++ -static-libgcc

Is your small test using those options?

Can you try linking GDB and testing GDB *without* those options?

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi David !

>>GDB is linked with static libstdc++ and libgcc.
>>-static-libstdc++ -static-libgcc
>>Is your small test using those options?

Yes, I used those static options. I am using readline library in my
test program and compiling it with gcc-6.1
like this:
g++ -g test.c -o test -static-libstdc++ -static-libgcc
-I/opt/freeware/include -lreadline
and the binary is working fine means I am able to catch the exceptions.

>>Can you try linking GDB and testing GDB *without* those options?
----Today I will be working on this---

Thanks,
Nitish


On Wed, Feb 8, 2017 at 7:02 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Wed, Feb 8, 2017 at 7:06 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 02/08/2017 06:16 AM, Nitish Kumar Mishra wrote:
>>
>>> I tried adding try/catch block earlier in throw_it and
>>> throw_exception_cxx functions
>>> but got no significant results.
>>> I had tried adding try catch block in these functions:
>>> kill_command
>>> command_handler
>>> command_line_handler
>>> execute_command
>>> throw_it
>>> throw_exception_cxx,
>>> but no progress. Output is exactly same as we got earlier (Other than
>>> extra frames for new
>>> try catch functions). None of the print statements in catch blocks for
>>> above functions worked.
>>
>> Eh, it sounds like _no_ exception catching works then?  I just
>> confirmed now that at least on GNU/Linux, GDB does not throw any
>> exception internally during startup.  This backtrace in question may
>> well not be special at all, and may be that _all_ exception catching
>> is broken.  I'd try experimenting with simple things like:
>>
>> try
>> {
>>   throw 1;
>> }
>> catch (...)
>> {
>>    printf (....);
>> }
>>
>> right at the start of gdb's main().  Not in a separately
>> compiled test program, but really inside gdb, to avoid
>> differences in how gdb vs the test program is built.
>>
>> It could also be that this is only triggered due to
>> GDB's binary size, hence not triggered in a small program -- I
>> recall that there was some trouble with the size of some sessions
>> and the linker in the AIX 7.1 box couldn't link gdb, or something
>> like that?  Maybe that's not fully/correctly sorted out.
>
> Nitish,
>
> GDB is linked with static libstdc++ and libgcc.
>
> -static-libstdc++ -static-libgcc
>
> Is your small test using those options?
>
> Can you try linking GDB and testing GDB *without* those options?
>
> Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi All !
Here is my findings about GCC- 4.8.5 and 6.1:


GCC-4.8.5 : 32 bit :::: (a) static linking to libstdc++
-----------------> [process getting terminated (not working)]
                                (b) dynamic linking
------------------------------>  [process getting terminated (not
working)]
                  64 bit :::: (a) static linking to libstdc++
-----------------> [working fine]
                                (b) dynamic linking
-------------------------------> [working fine]

GCC-6.1: 64 bit :::: (a) static linking to libstdc++
---------------------> [process getting terminated (not working)]
                             (b) dynamic linking
----------------------------------> [Unable to compile (compilation
error)]


Above, static linking meant WITH option -static-libstdc++
-static-libgcc and dynamic meant WITHOUT those options.

--------------------------------------------

Thanks,
Nitish


On Thu, Feb 9, 2017 at 10:21 AM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi David !
>
>>>GDB is linked with static libstdc++ and libgcc.
>>>-static-libstdc++ -static-libgcc
>>>Is your small test using those options?
>
> Yes, I used those static options. I am using readline library in my
> test program and compiling it with gcc-6.1
> like this:
> g++ -g test.c -o test -static-libstdc++ -static-libgcc
> -I/opt/freeware/include -lreadline
> and the binary is working fine means I am able to catch the exceptions.
>
>>>Can you try linking GDB and testing GDB *without* those options?
> ----Today I will be working on this---
>
> Thanks,
> Nitish
>
>
> On Wed, Feb 8, 2017 at 7:02 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> On Wed, Feb 8, 2017 at 7:06 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 02/08/2017 06:16 AM, Nitish Kumar Mishra wrote:
>>>
>>>> I tried adding try/catch block earlier in throw_it and
>>>> throw_exception_cxx functions
>>>> but got no significant results.
>>>> I had tried adding try catch block in these functions:
>>>> kill_command
>>>> command_handler
>>>> command_line_handler
>>>> execute_command
>>>> throw_it
>>>> throw_exception_cxx,
>>>> but no progress. Output is exactly same as we got earlier (Other than
>>>> extra frames for new
>>>> try catch functions). None of the print statements in catch blocks for
>>>> above functions worked.
>>>
>>> Eh, it sounds like _no_ exception catching works then?  I just
>>> confirmed now that at least on GNU/Linux, GDB does not throw any
>>> exception internally during startup.  This backtrace in question may
>>> well not be special at all, and may be that _all_ exception catching
>>> is broken.  I'd try experimenting with simple things like:
>>>
>>> try
>>> {
>>>   throw 1;
>>> }
>>> catch (...)
>>> {
>>>    printf (....);
>>> }
>>>
>>> right at the start of gdb's main().  Not in a separately
>>> compiled test program, but really inside gdb, to avoid
>>> differences in how gdb vs the test program is built.
>>>
>>> It could also be that this is only triggered due to
>>> GDB's binary size, hence not triggered in a small program -- I
>>> recall that there was some trouble with the size of some sessions
>>> and the linker in the AIX 7.1 box couldn't link gdb, or something
>>> like that?  Maybe that's not fully/correctly sorted out.
>>
>> Nitish,
>>
>> GDB is linked with static libstdc++ and libgcc.
>>
>> -static-libstdc++ -static-libgcc
>>
>> Is your small test using those options?
>>
>> Can you try linking GDB and testing GDB *without* those options?
>>
>> Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi all,
While sending the previous mail the statements got broken.
I am not sure if it is understandable. So, trying again :)

1. GDB with GCC-4.8.5, 32 bit mode, with or without static
    options : NOT WORKING.
2. GDB with GCC-4.8.5, 64 bit mode, with or without static
    options : WORKING FINE
3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING
4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR.

P.S.: Static options means: -static-libstdc++ -static-libgcc
----------------

Thanks,
Nitish

On Thu, Feb 9, 2017 at 5:35 PM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi All !
> Here is my findings about GCC- 4.8.5 and 6.1:
>
>
> GCC-4.8.5 : 32 bit :::: (a) static linking to libstdc++
> -----------------> [process getting terminated (not working)]
>                                 (b) dynamic linking
> ------------------------------>  [process getting terminated (not
> working)]
>                   64 bit :::: (a) static linking to libstdc++
> -----------------> [working fine]
>                                 (b) dynamic linking
> -------------------------------> [working fine]
>
> GCC-6.1: 64 bit :::: (a) static linking to libstdc++
> ---------------------> [process getting terminated (not working)]
>                              (b) dynamic linking
> ----------------------------------> [Unable to compile (compilation
> error)]
>
>
> Above, static linking meant WITH option -static-libstdc++
> -static-libgcc and dynamic meant WITHOUT those options.
>
> --------------------------------------------
>
> Thanks,
> Nitish
>
>
> On Thu, Feb 9, 2017 at 10:21 AM, Nitish Kumar Mishra
> <mishra.nitish.88@gmail.com> wrote:
>> Hi David !
>>
>>>>GDB is linked with static libstdc++ and libgcc.
>>>>-static-libstdc++ -static-libgcc
>>>>Is your small test using those options?
>>
>> Yes, I used those static options. I am using readline library in my
>> test program and compiling it with gcc-6.1
>> like this:
>> g++ -g test.c -o test -static-libstdc++ -static-libgcc
>> -I/opt/freeware/include -lreadline
>> and the binary is working fine means I am able to catch the exceptions.
>>
>>>>Can you try linking GDB and testing GDB *without* those options?
>> ----Today I will be working on this---
>>
>> Thanks,
>> Nitish
>>
>>
>> On Wed, Feb 8, 2017 at 7:02 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>>> On Wed, Feb 8, 2017 at 7:06 AM, Pedro Alves <palves@redhat.com> wrote:
>>>> On 02/08/2017 06:16 AM, Nitish Kumar Mishra wrote:
>>>>
>>>>> I tried adding try/catch block earlier in throw_it and
>>>>> throw_exception_cxx functions
>>>>> but got no significant results.
>>>>> I had tried adding try catch block in these functions:
>>>>> kill_command
>>>>> command_handler
>>>>> command_line_handler
>>>>> execute_command
>>>>> throw_it
>>>>> throw_exception_cxx,
>>>>> but no progress. Output is exactly same as we got earlier (Other than
>>>>> extra frames for new
>>>>> try catch functions). None of the print statements in catch blocks for
>>>>> above functions worked.
>>>>
>>>> Eh, it sounds like _no_ exception catching works then?  I just
>>>> confirmed now that at least on GNU/Linux, GDB does not throw any
>>>> exception internally during startup.  This backtrace in question may
>>>> well not be special at all, and may be that _all_ exception catching
>>>> is broken.  I'd try experimenting with simple things like:
>>>>
>>>> try
>>>> {
>>>>   throw 1;
>>>> }
>>>> catch (...)
>>>> {
>>>>    printf (....);
>>>> }
>>>>
>>>> right at the start of gdb's main().  Not in a separately
>>>> compiled test program, but really inside gdb, to avoid
>>>> differences in how gdb vs the test program is built.
>>>>
>>>> It could also be that this is only triggered due to
>>>> GDB's binary size, hence not triggered in a small program -- I
>>>> recall that there was some trouble with the size of some sessions
>>>> and the linker in the AIX 7.1 box couldn't link gdb, or something
>>>> like that?  Maybe that's not fully/correctly sorted out.
>>>
>>> Nitish,
>>>
>>> GDB is linked with static libstdc++ and libgcc.
>>>
>>> -static-libstdc++ -static-libgcc
>>>
>>> Is your small test using those options?
>>>
>>> Can you try linking GDB and testing GDB *without* those options?
>>>
>>> Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Thu, Feb 9, 2017 at 7:15 AM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi all,
> While sending the previous mail the statements got broken.
> I am not sure if it is understandable. So, trying again :)
>
> 1. GDB with GCC-4.8.5, 32 bit mode, with or without static
>     options : NOT WORKING.
> 2. GDB with GCC-4.8.5, 64 bit mode, with or without static
>     options : WORKING FINE

Okay.  This is why I was confused about GCC 4.8.5.  I don't have any
immediate intuition why 64 bit mode would have an effect on GCC.  To
me this implies a subtle AIX linker issue.  I have experienced AIX ld
behaving differently in 32 bit mode and 64 bit mode.

> 3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING
> 4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR.
>
> P.S.: Static options means: -static-libstdc++ -static-libgcc

What is the compilation error?

Does GCC 4.8.5 and GCC 6.1 fail in the same manner?  Neither catch the
exception?

GCC EH on AIX was improved (for GCC 6) to place EH tables in the
read-only section so that they could be shared and not bloat the data
section. This also changed the data encoding. But this change should
not have affected the algorithm to find an exception handler.

If it fails for both GCC 4.8 and GCC 6.1, that implies the problem is
not a recent GCC change.

It's possible that there is something wrong with the GCC code and it
accidentally works sometime, or it's possible that there is some bad
interaction between GCC and the AIX linker (like relocations or
ordering of symbols).

Because of the limited GDB functionality on AIX, debugging is
difficult. We need some more information about exactly why the EH
walker is failing to find the relevant EH frame.  What is wrong with
the table in the executable or in memory?

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi All,

> 3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING
> 4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR.
>
> P.S.: Static options means: -static-libstdc++ -static-libgcc

>What is the compilation error?
With GCC-6.1, 64 bit mode, WITHOUT static option, below is the output of the
compilation error:

ld: 0711-317 ERROR: Undefined symbol: ._Unwind_Resume
ld: 0711-317 ERROR: Undefined symbol: .__cxa_atexit
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status


> Does GCC 4.8.5 and GCC 6.1 fail in the same manner?  Neither catch the
exception?
Yes, by NOT WORKING, I meant, niether catching the exception and process is
getting terminated.

Thanks,
Nitish

On Thu, Feb 9, 2017 at 9:20 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Thu, Feb 9, 2017 at 7:15 AM, Nitish Kumar Mishra
> <mishra.nitish.88@gmail.com> wrote:
>> Hi all,
>> While sending the previous mail the statements got broken.
>> I am not sure if it is understandable. So, trying again :)
>>
>> 1. GDB with GCC-4.8.5, 32 bit mode, with or without static
>>     options : NOT WORKING.
>> 2. GDB with GCC-4.8.5, 64 bit mode, with or without static
>>     options : WORKING FINE
>
> Okay.  This is why I was confused about GCC 4.8.5.  I don't have any
> immediate intuition why 64 bit mode would have an effect on GCC.  To
> me this implies a subtle AIX linker issue.  I have experienced AIX ld
> behaving differently in 32 bit mode and 64 bit mode.
>
>> 3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING
>> 4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR.
>>
>> P.S.: Static options means: -static-libstdc++ -static-libgcc
>
> What is the compilation error?
>
> Does GCC 4.8.5 and GCC 6.1 fail in the same manner?  Neither catch the
> exception?
>
> GCC EH on AIX was improved (for GCC 6) to place EH tables in the
> read-only section so that they could be shared and not bloat the data
> section. This also changed the data encoding. But this change should
> not have affected the algorithm to find an exception handler.
>
> If it fails for both GCC 4.8 and GCC 6.1, that implies the problem is
> not a recent GCC change.
>
> It's possible that there is something wrong with the GCC code and it
> accidentally works sometime, or it's possible that there is some bad
> interaction between GCC and the AIX linker (like relocations or
> ordering of symbols).
>
> Because of the limited GDB functionality on AIX, debugging is
> difficult. We need some more information about exactly why the EH
> walker is failing to find the relevant EH frame.  What is wrong with
> the table in the executable or in memory?
>
> Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Fri, Feb 10, 2017 at 2:22 AM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi All,
>
>> 3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING
>> 4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR.
>>
>> P.S.: Static options means: -static-libstdc++ -static-libgcc
>
>>What is the compilation error?
> With GCC-6.1, 64 bit mode, WITHOUT static option, below is the output of the
> compilation error:
>
> ld: 0711-317 ERROR: Undefined symbol: ._Unwind_Resume
> ld: 0711-317 ERROR: Undefined symbol: .__cxa_atexit
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> collect2: error: ld returned 8 exit status
>
>
>> Does GCC 4.8.5 and GCC 6.1 fail in the same manner?  Neither catch the
> exception?
> Yes, by NOT WORKING, I meant, niether catching the exception and process is
> getting terminated.

Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?

The version of GCC that you are using was built incorrectly.  There
have been problems in the past with some of the pre-built binaries
containing libraries with recently added symbols not correctly
exported.

There seems to be a problem with exception handling and -static-libgcc
in recent versions of GCC on AIX.  I don't know what you have been
testing and why you were not able to triage this.

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Fri, Feb 10, 2017 at 10:52 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Fri, Feb 10, 2017 at 2:22 AM, Nitish Kumar Mishra
> <mishra.nitish.88@gmail.com> wrote:
>> Hi All,
>>
>>> 3. GDB with GCC-6.1, 64 bit mode, with static options : NOT WORKING
>>> 4. GDB with GCC-6.1, 64 bit mode, without static options : COMPILATION ERROR.
>>>
>>> P.S.: Static options means: -static-libstdc++ -static-libgcc
>>
>>>What is the compilation error?
>> With GCC-6.1, 64 bit mode, WITHOUT static option, below is the output of the
>> compilation error:
>>
>> ld: 0711-317 ERROR: Undefined symbol: ._Unwind_Resume
>> ld: 0711-317 ERROR: Undefined symbol: .__cxa_atexit
>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
>> collect2: error: ld returned 8 exit status
>>
>>
>>> Does GCC 4.8.5 and GCC 6.1 fail in the same manner?  Neither catch the
>> exception?
>> Yes, by NOT WORKING, I meant, niether catching the exception and process is
>> getting terminated.
>
> Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
>
> The version of GCC that you are using was built incorrectly.  There
> have been problems in the past with some of the pre-built binaries
> containing libraries with recently added symbols not correctly
> exported.
>
> There seems to be a problem with exception handling and -static-libgcc
> in recent versions of GCC on AIX.  I don't know what you have been
> testing and why you were not able to triage this.

Investigating the exception handling problem with another non-IBM AIX
developer, the problem appears to be that statically linking libgcc
and libstdc++ create two, separate and distinct copies of the unwind
tables.  These tables are not merged and the unwinder cannot find the
EH catcher.  It's not immediately clear why this worked in GCC 4.8 and
not in GCC 4.9 and later.

GDB with exception handling should work if libgcc and libstdc++ are
linked as shared libraries.  The linking error with GCC 6.1 is cockpit
error.

Can we disable -static-libgcc and -static-libstdc++ for AIX?

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Pedro Alves]

On 02/12/2017 09:05 PM, David Edelsohn wrote:

> Investigating the exception handling problem with another non-IBM AIX
> developer, the problem appears to be that statically linking libgcc
> and libstdc++ create two, separate and distinct copies of the unwind
> tables.  These tables are not merged and the unwinder cannot find the
> EH catcher.  It's not immediately clear why this worked in GCC 4.8 and
> not in GCC 4.9 and later.
> 
> GDB with exception handling should work if libgcc and libstdc++ are
> linked as shared libraries.  The linking error with GCC 6.1 is cockpit
> error.
> 
> Can we disable -static-libgcc and -static-libstdc++ for AIX?

Works for me.  Those are added by the top level configure.  They were
originally added for gcc, we just inherited it.  Ideally adding
those would be controllable with a configure option, IMO.

Thanks,
Pedro Alves

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

On Sun, Feb 12, 2017 at 6:52 PM, Pedro Alves <pedro@palves.net> wrote:
> On 02/12/2017 09:05 PM, David Edelsohn wrote:
>
>> Investigating the exception handling problem with another non-IBM AIX
>> developer, the problem appears to be that statically linking libgcc
>> and libstdc++ create two, separate and distinct copies of the unwind
>> tables.  These tables are not merged and the unwinder cannot find the
>> EH catcher.  It's not immediately clear why this worked in GCC 4.8 and
>> not in GCC 4.9 and later.
>>
>> GDB with exception handling should work if libgcc and libstdc++ are
>> linked as shared libraries.  The linking error with GCC 6.1 is cockpit
>> error.
>>
>> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>
> Works for me.  Those are added by the top level configure.  They were
> originally added for gcc, we just inherited it.  Ideally adding
> those would be controllable with a configure option, IMO.

We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
static would be better.  But linking GDB dynamically could be helpful
as an interim work-around.

Thanks, David

Re: Issue with Latest GDB on AIX with GCC-6.12

[Eli Zaretskii]

> From: David Edelsohn <dje.gcc@gmail.com>
> Date: Mon, 13 Feb 2017 10:02:35 -0500
> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>, 	Yao Qi <qiyaoltc@gmail.com>
> 
> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
> >
> > Works for me.  Those are added by the top level configure.  They were
> > originally added for gcc, we just inherited it.  Ideally adding
> > those would be controllable with a configure option, IMO.
> 
> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
> static would be better.  But linking GDB dynamically could be helpful
> as an interim work-around.

Please let's not do that on MS-Windows at least.  Dynamically linking
against these two libraries has the following 2 adverse effects:

  . it requires any site that distributes precompiled Windows binaries
    of GDB to also distribute the full humongous tarball of GCC
    sources (because libgcc runtime exception doesn't cover dynamic
    linking against shared libraries); and

  . it opens the gates of the "DLL hell", since there's any number of
    libgcc and libstdc++ DLLs from different versions of GCC floating
    around on any given Windows system with GNU software, and there's
    no practical way to ensure binary compatibility between the one
    found first on PATH and a particular version of GDB one wants to
    run

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi David !

>Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our
environment. I took it from perzl.org.
But now I have tested it with Bull's RPM, static linking still not
working but removing --static-libstdc++ and --static-libgcc
is working for me as well.
Now, I will run the testsuite and will paste the result once it's finished.

I disabled the static options manually. I don't see any configure
option for disabling the static linking. I tried with one configure
option --disable-libstdcxx, but I dont think it will lead to dynamic
linking. Anyways, for me, using this option --disable-libstdcxx
was giving compilation error, saying, "ld soes not support target".

Thanks,
Nitish


On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: David Edelsohn <dje.gcc@gmail.com>
>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>,      Yao Qi <qiyaoltc@gmail.com>
>>
>> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>> >
>> > Works for me.  Those are added by the top level configure.  They were
>> > originally added for gcc, we just inherited it.  Ideally adding
>> > those would be controllable with a configure option, IMO.
>>
>> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
>> static would be better.  But linking GDB dynamically could be helpful
>> as an interim work-around.
>
> Please let's not do that on MS-Windows at least.  Dynamically linking
> against these two libraries has the following 2 adverse effects:
>
>   . it requires any site that distributes precompiled Windows binaries
>     of GDB to also distribute the full humongous tarball of GCC
>     sources (because libgcc runtime exception doesn't cover dynamic
>     linking against shared libraries); and
>
>   . it opens the gates of the "DLL hell", since there's any number of
>     libgcc and libstdc++ DLLs from different versions of GCC floating
>     around on any given Windows system with GNU software, and there's
>     no practical way to ensure binary compatibility between the one
>     found first on PATH and a particular version of GDB one wants to
>     run

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi All !

I have created a bug for this issue. The bug id is: 21187.
I have created a patch for configure file in which new configure
option --enable-staticlib and --disable-staticlib is implemented.
By default the linking of GDB with libstdc++ and libgcc will be static.

Attching the patch with the mail.

On Mon, Feb 13, 2017 at 9:08 PM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi David !
>
>>Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
> IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our
> environment. I took it from perzl.org.
> But now I have tested it with Bull's RPM, static linking still not
> working but removing --static-libstdc++ and --static-libgcc
> is working for me as well.
> Now, I will run the testsuite and will paste the result once it's finished.
>
> I disabled the static options manually. I don't see any configure
> option for disabling the static linking. I tried with one configure
> option --disable-libstdcxx, but I dont think it will lead to dynamic
> linking. Anyways, for me, using this option --disable-libstdcxx
> was giving compilation error, saying, "ld soes not support target".
>
> Thanks,
> Nitish
>
>
> On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: David Edelsohn <dje.gcc@gmail.com>
>>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>>> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>,      Yao Qi <qiyaoltc@gmail.com>
>>>
>>> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>>> >
>>> > Works for me.  Those are added by the top level configure.  They were
>>> > originally added for gcc, we just inherited it.  Ideally adding
>>> > those would be controllable with a configure option, IMO.
>>>
>>> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
>>> static would be better.  But linking GDB dynamically could be helpful
>>> as an interim work-around.
>>
>> Please let's not do that on MS-Windows at least.  Dynamically linking
>> against these two libraries has the following 2 adverse effects:
>>
>>   . it requires any site that distributes precompiled Windows binaries
>>     of GDB to also distribute the full humongous tarball of GCC
>>     sources (because libgcc runtime exception doesn't cover dynamic
>>     linking against shared libraries); and
>>
>>   . it opens the gates of the "DLL hell", since there's any number of
>>     libgcc and libstdc++ DLLs from different versions of GCC floating
>>     around on any given Windows system with GNU software, and there's
>>     no practical way to ensure binary compatibility between the one
>>     found first on PATH and a particular version of GDB one wants to
>>     run

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

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

Hi All !

Please find the patch attachment with this mail.
Any comments are more than welcome.

Thanks,
Nitish

On Mon, Feb 20, 2017 at 4:52 PM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi All !
>
> I have created a bug for this issue. The bug id is: 21187.
> I have created a patch for configure file in which new configure
> option --enable-staticlib and --disable-staticlib is implemented.
> By default the linking of GDB with libstdc++ and libgcc will be static.
>
> Attching the patch with the mail.
>
> On Mon, Feb 13, 2017 at 9:08 PM, Nitish Kumar Mishra
> <mishra.nitish.88@gmail.com> wrote:
>> Hi David !
>>
>>>Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
>> IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our
>> environment. I took it from perzl.org.
>> But now I have tested it with Bull's RPM, static linking still not
>> working but removing --static-libstdc++ and --static-libgcc
>> is working for me as well.
>> Now, I will run the testsuite and will paste the result once it's finished.
>>
>> I disabled the static options manually. I don't see any configure
>> option for disabling the static linking. I tried with one configure
>> option --disable-libstdcxx, but I dont think it will lead to dynamic
>> linking. Anyways, for me, using this option --disable-libstdcxx
>> was giving compilation error, saying, "ld soes not support target".
>>
>> Thanks,
>> Nitish
>>
>>
>> On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> From: David Edelsohn <dje.gcc@gmail.com>
>>>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>>>> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>,      Yao Qi <qiyaoltc@gmail.com>
>>>>
>>>> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>>>> >
>>>> > Works for me.  Those are added by the top level configure.  They were
>>>> > originally added for gcc, we just inherited it.  Ideally adding
>>>> > those would be controllable with a configure option, IMO.
>>>>
>>>> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
>>>> static would be better.  But linking GDB dynamically could be helpful
>>>> as an interim work-around.
>>>
>>> Please let's not do that on MS-Windows at least.  Dynamically linking
>>> against these two libraries has the following 2 adverse effects:
>>>
>>>   . it requires any site that distributes precompiled Windows binaries
>>>     of GDB to also distribute the full humongous tarball of GCC
>>>     sources (because libgcc runtime exception doesn't cover dynamic
>>>     linking against shared libraries); and
>>>
>>>   . it opens the gates of the "DLL hell", since there's any number of
>>>     libgcc and libstdc++ DLLs from different versions of GCC floating
>>>     around on any given Windows system with GNU software, and there's
>>>     no practical way to ensure binary compatibility between the one
>>>     found first on PATH and a particular version of GDB one wants to
>>>     run

[-- Attachment #2: disable_static_link_aix.patch --]
[-- Type: application/octet-stream, Size: 2419 bytes --]

--- configure_org	2017-01-06 04:12:08.000000000 -0600
+++ configure	2017-02-20 04:34:10.000000000 -0600
@@ -760,6 +760,7 @@
  enable_libada
  enable_libssp
  enable_libstdcxx
+ enable_staticlib
  enable_liboffloadmic
  enable_static_libjava
  enable_bootstrap
@@ -1487,6 +1488,7 @@
    --enable-libada         build libada directory
    --enable-libssp         build libssp directory
    --disable-libstdcxx     do not build libstdc++-v3 directory
+   --disable-staticlib	  disable static linking of libstdc++ and libgcc
    --enable-liboffloadmic=ARG
                            build liboffloadmic [ARG={no,host,target}]
    --enable-static-libjava[=ARG]
@@ -3106,6 +3108,14 @@
    ENABLE_LIBSTDCXX=default
  fi
  
+ # Check whether --disable-staticlib was given.
+ if test "${enable_staticlib+set}" = set; then 
+   enableval=$enable_staticlib; 
+   ENABLE_STATICLIB=$enableval;
+ else
+   ENABLE_STATICLIB=yes;
+ fi
+ 
  if test "${ENABLE_LIBSTDCXX}" = "no" ; then
    noconfigdirs="$noconfigdirs target-libstdc++-v3"
  fi
@@ -5109,9 +5119,11 @@
    fi
  fi
  
- # Check whether -static-libstdc++ -static-libgcc is supported.
+ 
  have_static_libs=no
- if test "$GCC" = yes; then
+ # If enable_staticlib is set for configuration, check whether -static-libstdc++ -static-libgcc is supported.
+ if test "$ENABLE_STATICLIB" = yes; then 
+  if test "$GCC" = yes; then
    saved_LDFLAGS="$LDFLAGS"
  
    LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
@@ -5150,10 +5162,10 @@
  
    LDFLAGS="$saved_LDFLAGS"
  fi
+ fi
  
  
  
- 
  if test -n "$ac_tool_prefix"; then
    # Extract the first word of "${ac_tool_prefix}gnatbind", so it can be a program name with args.
  set dummy ${ac_tool_prefix}gnatbind; ac_word=$2
@@ -5903,6 +5915,9 @@
   # trust that they are doing what they want.
   if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
     stage1_ldflags="-static-libstdc++ -static-libgcc"
+   else
+   # If static lib is disabled.
+    stage1_ldflags=""
   fi
  fi
  
@@ -5937,8 +5952,10 @@
   # In stages 2 and 3, default to linking libstdc++ and libgcc
   # statically.  But if the user explicitly specified the libraries to
   # use, trust that they are doing what they want.
-  if test "$poststage1_libs" = ""; then
+  if test "$poststage1_libs" = "" -a $ENABLE_STATICLIB = yes; then
     poststage1_ldflags="-static-libstdc++ -static-libgcc"
+   else
+    poststage1_ldflags=""
   fi
  fi
  

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi All !
The proposed patch is tested on AIX-7.2 and Ubuntu-16.04 and it seems
to be working fine.

Thanks,
Nitish.

On Mon, Feb 20, 2017 at 4:55 PM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi All !
>
> Please find the patch attachment with this mail.
> Any comments are more than welcome.
>
> Thanks,
> Nitish
>
> On Mon, Feb 20, 2017 at 4:52 PM, Nitish Kumar Mishra
> <mishra.nitish.88@gmail.com> wrote:
>> Hi All !
>>
>> I have created a bug for this issue. The bug id is: 21187.
>> I have created a patch for configure file in which new configure
>> option --enable-staticlib and --disable-staticlib is implemented.
>> By default the linking of GDB with libstdc++ and libgcc will be static.
>>
>> Attching the patch with the mail.
>>
>> On Mon, Feb 13, 2017 at 9:08 PM, Nitish Kumar Mishra
>> <mishra.nitish.88@gmail.com> wrote:
>>> Hi David !
>>>
>>>>Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
>>> IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our
>>> environment. I took it from perzl.org.
>>> But now I have tested it with Bull's RPM, static linking still not
>>> working but removing --static-libstdc++ and --static-libgcc
>>> is working for me as well.
>>> Now, I will run the testsuite and will paste the result once it's finished.
>>>
>>> I disabled the static options manually. I don't see any configure
>>> option for disabling the static linking. I tried with one configure
>>> option --disable-libstdcxx, but I dont think it will lead to dynamic
>>> linking. Anyways, for me, using this option --disable-libstdcxx
>>> was giving compilation error, saying, "ld soes not support target".
>>>
>>> Thanks,
>>> Nitish
>>>
>>>
>>> On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>> From: David Edelsohn <dje.gcc@gmail.com>
>>>>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>>>>> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>,      Yao Qi <qiyaoltc@gmail.com>
>>>>>
>>>>> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>>>>> >
>>>>> > Works for me.  Those are added by the top level configure.  They were
>>>>> > originally added for gcc, we just inherited it.  Ideally adding
>>>>> > those would be controllable with a configure option, IMO.
>>>>>
>>>>> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
>>>>> static would be better.  But linking GDB dynamically could be helpful
>>>>> as an interim work-around.
>>>>
>>>> Please let's not do that on MS-Windows at least.  Dynamically linking
>>>> against these two libraries has the following 2 adverse effects:
>>>>
>>>>   . it requires any site that distributes precompiled Windows binaries
>>>>     of GDB to also distribute the full humongous tarball of GCC
>>>>     sources (because libgcc runtime exception doesn't cover dynamic
>>>>     linking against shared libraries); and
>>>>
>>>>   . it opens the gates of the "DLL hell", since there's any number of
>>>>     libgcc and libstdc++ DLLs from different versions of GCC floating
>>>>     around on any given Windows system with GNU software, and there's
>>>>     no practical way to ensure binary compatibility between the one
>>>>     found first on PATH and a particular version of GDB one wants to
>>>>     run

Re: Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

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

Hi All !

The previous patch file has issues while patching. I mistakenly sent it.
I am attaching the updated one.

Thanks and Regards
Nitish.

On Mon, Feb 20, 2017 at 5:07 PM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi All !
> The proposed patch is tested on AIX-7.2 and Ubuntu-16.04 and it seems
> to be working fine.
>
> Thanks,
> Nitish.
>
> On Mon, Feb 20, 2017 at 4:55 PM, Nitish Kumar Mishra
> <mishra.nitish.88@gmail.com> wrote:
>> Hi All !
>>
>> Please find the patch attachment with this mail.
>> Any comments are more than welcome.
>>
>> Thanks,
>> Nitish
>>
>> On Mon, Feb 20, 2017 at 4:52 PM, Nitish Kumar Mishra
>> <mishra.nitish.88@gmail.com> wrote:
>>> Hi All !
>>>
>>> I have created a bug for this issue. The bug id is: 21187.
>>> I have created a patch for configure file in which new configure
>>> option --enable-staticlib and --disable-staticlib is implemented.
>>> By default the linking of GDB with libstdc++ and libgcc will be static.
>>>
>>> Attching the patch with the mail.
>>>
>>> On Mon, Feb 13, 2017 at 9:08 PM, Nitish Kumar Mishra
>>> <mishra.nitish.88@gmail.com> wrote:
>>>> Hi David !
>>>>
>>>>>Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
>>>> IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our
>>>> environment. I took it from perzl.org.
>>>> But now I have tested it with Bull's RPM, static linking still not
>>>> working but removing --static-libstdc++ and --static-libgcc
>>>> is working for me as well.
>>>> Now, I will run the testsuite and will paste the result once it's finished.
>>>>
>>>> I disabled the static options manually. I don't see any configure
>>>> option for disabling the static linking. I tried with one configure
>>>> option --disable-libstdcxx, but I dont think it will lead to dynamic
>>>> linking. Anyways, for me, using this option --disable-libstdcxx
>>>> was giving compilation error, saying, "ld soes not support target".
>>>>
>>>> Thanks,
>>>> Nitish
>>>>
>>>>
>>>> On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>>> From: David Edelsohn <dje.gcc@gmail.com>
>>>>>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>>>>>> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>,      Yao Qi <qiyaoltc@gmail.com>
>>>>>>
>>>>>> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>>>>>> >
>>>>>> > Works for me.  Those are added by the top level configure.  They were
>>>>>> > originally added for gcc, we just inherited it.  Ideally adding
>>>>>> > those would be controllable with a configure option, IMO.
>>>>>>
>>>>>> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
>>>>>> static would be better.  But linking GDB dynamically could be helpful
>>>>>> as an interim work-around.
>>>>>
>>>>> Please let's not do that on MS-Windows at least.  Dynamically linking
>>>>> against these two libraries has the following 2 adverse effects:
>>>>>
>>>>>   . it requires any site that distributes precompiled Windows binaries
>>>>>     of GDB to also distribute the full humongous tarball of GCC
>>>>>     sources (because libgcc runtime exception doesn't cover dynamic
>>>>>     linking against shared libraries); and
>>>>>
>>>>>   . it opens the gates of the "DLL hell", since there's any number of
>>>>>     libgcc and libstdc++ DLLs from different versions of GCC floating
>>>>>     around on any given Windows system with GNU software, and there's
>>>>>     no practical way to ensure binary compatibility between the one
>>>>>     found first on PATH and a particular version of GDB one wants to
>>>>>     run

[-- Attachment #2: disable_static_link_aix.patch --]
[-- Type: application/octet-stream, Size: 2162 bytes --]

--- configure.ORIG	2017-02-21 12:57:12.609299019 +0530
+++ configure	2017-02-21 13:00:09.385643019 +0530
@@ -760,6 +760,7 @@
 enable_libada
 enable_libssp
 enable_libstdcxx
+enable_staticlib
 enable_liboffloadmic
 enable_static_libjava
 enable_bootstrap
@@ -1487,6 +1488,7 @@
   --enable-libada         build libada directory
   --enable-libssp         build libssp directory
   --disable-libstdcxx     do not build libstdc++-v3 directory
+  --disable-staticlib	  disable static linking of libstdc++ and libgcc
   --enable-liboffloadmic=ARG
                           build liboffloadmic [ARG={no,host,target}]
   --enable-static-libjava[=ARG]
@@ -3106,6 +3108,14 @@
   ENABLE_LIBSTDCXX=default
 fi
 
+# Check whether --disable-staticlib was given.
+if test "${enable_staticlib+set}" = set; then 
+  enableval=$enable_staticlib; 
+  ENABLE_STATICLIB=$enableval;
+else
+  ENABLE_STATICLIB=yes;
+fi
+
 if test "${ENABLE_LIBSTDCXX}" = "no" ; then
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
 fi
@@ -5109,9 +5119,11 @@
   fi
 fi
 
-# Check whether -static-libstdc++ -static-libgcc is supported.
+
 have_static_libs=no
-if test "$GCC" = yes; then
+# If enable_staticlib is set for configuration, check whether -static-libstdc++ -static-libgcc is supported.
+if test "$ENABLE_STATICLIB" = yes; then 
+ if test "$GCC" = yes; then
   saved_LDFLAGS="$LDFLAGS"
 
   LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
@@ -5150,7 +5162,7 @@
 
   LDFLAGS="$saved_LDFLAGS"
 fi
-
+fi
 
 
 
@@ -5903,6 +5915,9 @@
  # trust that they are doing what they want.
  if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
    stage1_ldflags="-static-libstdc++ -static-libgcc"
+  else
+  # If static lib is disabled.
+   stage1_ldflags=""
  fi
 fi
 
@@ -5937,8 +5952,10 @@
  # In stages 2 and 3, default to linking libstdc++ and libgcc
  # statically.  But if the user explicitly specified the libraries to
  # use, trust that they are doing what they want.
- if test "$poststage1_libs" = ""; then
+ if test "$poststage1_libs" = "" -a $ENABLE_STATICLIB = yes; then
    poststage1_ldflags="-static-libstdc++ -static-libgcc"
+  else
+   poststage1_ldflags=""
  fi
 fi
 

Re: Issue with Latest GDB on AIX with GCC-6.12

[David Edelsohn]

Nitish,

Patches should be sent to the gdb-patches mailing list with a new
email thread. Please follow the format for email subject lines.

configure is a generated file, so you must patch configure.ac and then
be able to use the correct version of autoconf to regenerate the file.

There already is a variable have_static_libs, so it may be more useful
to re-use that variable than to create another one with much the same
functionality.

Thanks, David

On Tue, Feb 21, 2017 at 12:00 AM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> Hi All !
>
> The previous patch file has issues while patching. I mistakenly sent it.
> I am attaching the updated one.
>
> Thanks and Regards
> Nitish.
>
> On Mon, Feb 20, 2017 at 5:07 PM, Nitish Kumar Mishra
> <mishra.nitish.88@gmail.com> wrote:
>> Hi All !
>> The proposed patch is tested on AIX-7.2 and Ubuntu-16.04 and it seems
>> to be working fine.
>>
>> Thanks,
>> Nitish.
>>
>> On Mon, Feb 20, 2017 at 4:55 PM, Nitish Kumar Mishra
>> <mishra.nitish.88@gmail.com> wrote:
>>> Hi All !
>>>
>>> Please find the patch attachment with this mail.
>>> Any comments are more than welcome.
>>>
>>> Thanks,
>>> Nitish
>>>
>>> On Mon, Feb 20, 2017 at 4:52 PM, Nitish Kumar Mishra
>>> <mishra.nitish.88@gmail.com> wrote:
>>>> Hi All !
>>>>
>>>> I have created a bug for this issue. The bug id is: 21187.
>>>> I have created a patch for configure file in which new configure
>>>> option --enable-staticlib and --disable-staticlib is implemented.
>>>> By default the linking of GDB with libstdc++ and libgcc will be static.
>>>>
>>>> Attching the patch with the mail.
>>>>
>>>> On Mon, Feb 13, 2017 at 9:08 PM, Nitish Kumar Mishra
>>>> <mishra.nitish.88@gmail.com> wrote:
>>>>> Hi David !
>>>>>
>>>>>>Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
>>>>> IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our
>>>>> environment. I took it from perzl.org.
>>>>> But now I have tested it with Bull's RPM, static linking still not
>>>>> working but removing --static-libstdc++ and --static-libgcc
>>>>> is working for me as well.
>>>>> Now, I will run the testsuite and will paste the result once it's finished.
>>>>>
>>>>> I disabled the static options manually. I don't see any configure
>>>>> option for disabling the static linking. I tried with one configure
>>>>> option --disable-libstdcxx, but I dont think it will lead to dynamic
>>>>> linking. Anyways, for me, using this option --disable-libstdcxx
>>>>> was giving compilation error, saying, "ld soes not support target".
>>>>>
>>>>> Thanks,
>>>>> Nitish
>>>>>
>>>>>
>>>>> On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>>>> From: David Edelsohn <dje.gcc@gmail.com>
>>>>>>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>>>>>>> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>,      Yao Qi <qiyaoltc@gmail.com>
>>>>>>>
>>>>>>> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>>>>>>> >
>>>>>>> > Works for me.  Those are added by the top level configure.  They were
>>>>>>> > originally added for gcc, we just inherited it.  Ideally adding
>>>>>>> > those would be controllable with a configure option, IMO.
>>>>>>>
>>>>>>> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
>>>>>>> static would be better.  But linking GDB dynamically could be helpful
>>>>>>> as an interim work-around.
>>>>>>
>>>>>> Please let's not do that on MS-Windows at least.  Dynamically linking
>>>>>> against these two libraries has the following 2 adverse effects:
>>>>>>
>>>>>>   . it requires any site that distributes precompiled Windows binaries
>>>>>>     of GDB to also distribute the full humongous tarball of GCC
>>>>>>     sources (because libgcc runtime exception doesn't cover dynamic
>>>>>>     linking against shared libraries); and
>>>>>>
>>>>>>   . it opens the gates of the "DLL hell", since there's any number of
>>>>>>     libgcc and libstdc++ DLLs from different versions of GCC floating
>>>>>>     around on any given Windows system with GNU software, and there's
>>>>>>     no practical way to ensure binary compatibility between the one
>>>>>>     found first on PATH and a particular version of GDB one wants to
>>>>>>     run