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

[Nitish Kumar Mishra <mishra.nitish.88@gmail.com>]

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