This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]