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

Nitish Kumar Mishra <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CACC+hkgFOO6xRk38-jUhpyt+HGHiEeD60RDpi_5KX4XD+kA=1w@mail.gmail.com>
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
<[email protected]> 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 <[email protected]> wrote:
>> On Wed, Feb 8, 2017 at 7:06 AM, Pedro Alves <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.