Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* GDB on AIX
@ 2016-11-14 15:51 Yao Qi
  2016-11-14 16:17 ` David Edelsohn
  2016-11-14 17:18 ` Pedro Alves
  0 siblings, 2 replies; 10+ messages in thread
From: Yao Qi @ 2016-11-14 15:51 UTC (permalink / raw)
  To: GDB, David Edelsohn, Sergio Durigan Junior

Hi David and Sergio,

GDB mainline is broken on aix (gcc119.fsffrance.org),

$ ./gdb
GNU gdb (GDB) 7.12.50.20161114-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) kill
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
IOT/Abort trap (core dumped)

Although we have an aix buildslave on this machine,
I don't think anyone checked the test result carefully.
Here is the first build on this buildslave (on Aug)
http://gdb-build.sergiodj.net/builders/AIX-POWER8-plain/builds/1/steps/regressions/logs/stdio
There are a lot of "UNRESOLVED" and "ERROR", and
summary looks wrong as well, which has only 2330 passes,
but 8323 unresolved.

=== gdb Summary ===

# of expected passes 2330
# of unexpected failures 78
# of expected failures 7
# of known failures 1
# of untested testcases 134
# of unresolved testcases 8323
# of unsupported tests 178

I think Pedro fixed this issue
https://sourceware.org/ml/gdb-patches/2016-04/msg00504.html before,
but I only verified the fix on native arm-linux on reviewing Pedro's fix.
I am not sure it is related to aix 7.1 -> aix 7.2 change.

-- 
Yao (齐尧)


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: GDB on AIX
  2016-11-14 15:51 GDB on AIX Yao Qi
@ 2016-11-14 16:17 ` David Edelsohn
  2016-11-14 17:18 ` Pedro Alves
  1 sibling, 0 replies; 10+ messages in thread
From: David Edelsohn @ 2016-11-14 16:17 UTC (permalink / raw)
  To: Yao Qi; +Cc: GDB, Sergio Durigan Junior

You can see the history of the builder

http://gdb-build.sergiodj.net/builders/AIX-POWER8-plain

- David


On Mon, Nov 14, 2016 at 10:51 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
> Hi David and Sergio,
>
> GDB mainline is broken on aix (gcc119.fsffrance.org),
>
> $ ./gdb
> GNU gdb (GDB) 7.12.50.20161114-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc-ibm-aix7.2.0.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) kill
> terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
> IOT/Abort trap (core dumped)
>
> Although we have an aix buildslave on this machine,
> I don't think anyone checked the test result carefully.
> Here is the first build on this buildslave (on Aug)
> http://gdb-build.sergiodj.net/builders/AIX-POWER8-plain/builds/1/steps/regressions/logs/stdio
> There are a lot of "UNRESOLVED" and "ERROR", and
> summary looks wrong as well, which has only 2330 passes,
> but 8323 unresolved.
>
> === gdb Summary ===
>
> # of expected passes 2330
> # of unexpected failures 78
> # of expected failures 7
> # of known failures 1
> # of untested testcases 134
> # of unresolved testcases 8323
> # of unsupported tests 178
>
> I think Pedro fixed this issue
> https://sourceware.org/ml/gdb-patches/2016-04/msg00504.html before,
> but I only verified the fix on native arm-linux on reviewing Pedro's fix.
> I am not sure it is related to aix 7.1 -> aix 7.2 change.
>
> --
> Yao (齐尧)


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: GDB on AIX
  2016-11-14 15:51 GDB on AIX Yao Qi
  2016-11-14 16:17 ` David Edelsohn
@ 2016-11-14 17:18 ` Pedro Alves
  2016-11-14 17:35   ` David Edelsohn
  2016-11-14 22:16   ` Yao Qi
  1 sibling, 2 replies; 10+ messages in thread
From: Pedro Alves @ 2016-11-14 17:18 UTC (permalink / raw)
  To: Yao Qi, GDB, David Edelsohn, Sergio Durigan Junior

On 11/14/2016 03:51 PM, Yao Qi wrote:
> Hi David and Sergio,
> 
> GDB mainline is broken on aix (gcc119.fsffrance.org),


> (gdb) kill
> terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
> IOT/Abort trap (core dumped)

If you debug gdb and put a breakpoint on throw_it, what does the
backtrace look like?  Would be exception be crossing 
some C library that doesn't understand C++ exceptions,
other than readline?

Thanks,
Pedro Alves


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: GDB on AIX
  2016-11-14 17:18 ` Pedro Alves
@ 2016-11-14 17:35   ` David Edelsohn
  2016-11-14 17:44     ` Pedro Alves
  2016-11-14 22:16   ` Yao Qi
  1 sibling, 1 reply; 10+ messages in thread
From: David Edelsohn @ 2016-11-14 17:35 UTC (permalink / raw)
  To: Pedro Alves; +Cc: Yao Qi, GDB, Sergio Durigan Junior

On Mon, Nov 14, 2016 at 12:18 PM, Pedro Alves <palves@redhat.com> wrote:
> On 11/14/2016 03:51 PM, Yao Qi wrote:
>> Hi David and Sergio,
>>
>> GDB mainline is broken on aix (gcc119.fsffrance.org),
>
>> (gdb) kill
>> terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
>> IOT/Abort trap (core dumped)
>
> If you debug gdb and put a breakpoint on throw_it, what does the
> backtrace look like?  Would be exception be crossing
> some C library that doesn't understand C++ exceptions,
> other than readline?

Does the code assume that it can through an exception through a system library?

- David


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: GDB on AIX
  2016-11-14 17:35   ` David Edelsohn
@ 2016-11-14 17:44     ` Pedro Alves
  0 siblings, 0 replies; 10+ messages in thread
From: Pedro Alves @ 2016-11-14 17:44 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Yao Qi, GDB, Sergio Durigan Junior

On 11/14/2016 05:35 PM, David Edelsohn wrote:
> On Mon, Nov 14, 2016 at 12:18 PM, Pedro Alves <palves@redhat.com> wrote:
>> On 11/14/2016 03:51 PM, Yao Qi wrote:
>>> Hi David and Sergio,
>>>
>>> GDB mainline is broken on aix (gcc119.fsffrance.org),
>>
>>> (gdb) kill
>>> terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
>>> IOT/Abort trap (core dumped)
>>
>> If you debug gdb and put a breakpoint on throw_it, what does the
>> backtrace look like?  Would be exception be crossing
>> some C library that doesn't understand C++ exceptions,
>> other than readline?
> 
> Does the code assume that it can through an exception through a system library?

It shouldn't of course, but since we used to implement our own
home grown exception scheme using setjmp/longjmp, there may be
places that do throw across system libraries that happen to work
on x86-64 (and thus go unnoticed) because these system libraries are
built with -fexceptions.  The url Yao pointed at before was a series
fixing one such case.  I had confirmed at the time that that fixed
AIX, though (the older machine), so it's a bit puzzling.

Thanks,
Pedro Alves


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: GDB on AIX
  2016-11-14 17:18 ` Pedro Alves
  2016-11-14 17:35   ` David Edelsohn
@ 2016-11-14 22:16   ` Yao Qi
  1 sibling, 0 replies; 10+ messages in thread
From: Yao Qi @ 2016-11-14 22:16 UTC (permalink / raw)
  To: Pedro Alves; +Cc: GDB, David Edelsohn, Sergio Durigan Junior

On Mon, Nov 14, 2016 at 05:18:31PM +0000, Pedro Alves wrote:
> On 11/14/2016 03:51 PM, Yao Qi wrote:
> > Hi David and Sergio,
> >
> > GDB mainline is broken on aix (gcc119.fsffrance.org),
>
>
> > (gdb) kill
> > terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
> > IOT/Abort trap (core dumped)
>
> If you debug gdb and put a breakpoint on throw_it, what does the
> backtrace look like?  Would be exception be crossing
> some C library that doesn't understand C++ exceptions,
> other than readline?
>

I don't see any C library other than readline,

(top-gdb) bt
#0  _ZL8throw_it13return_reason6errorsPKcPc (reason=1, error=538192296,
    fmt=0x105cebcc <_GLOBAL__F_inferior_ptid+5836> "The program is not
being run.", ap=0x2ff2253c "/Ã")
    at ../../binutils-gdb/gdb/common/common-exceptions.c:345
#1  0x10031390 in _Z12throw_verror6errorsPKcPc (error=4294967295, fmt=0x1 "",
    ap=0x105cebcc <_GLOBAL__F_inferior_ptid+5836> "The program is not
being run.") at ../../binutils-gdb/gdb/common/common-exceptions.c:379
#2  0x1000f940 in _Z6verrorPKcPc (string=0xffffffff <error: Cannot
access memory at address 0xffffffff>, args=0x1 "")
    at ../../binutils-gdb/gdb/utils.c:477
#3  0x1002e6a4 in _Z5errorPKcz (fmt=0xffffffff <error: Cannot access
memory at address 0xffffffff>) at
../../binutils-gdb/gdb/common/errors.c:43
#4  0x100d9170 in _ZL12kill_commandPci (arg=0xffffffff <error: Cannot
access memory at address 0xffffffff>, from_tty=1)
    at ../../binutils-gdb/gdb/infcmd.c:2578
#5  0x1008b5c8 in _ZL8do_cfuncP16cmd_list_elementPci (c=0xffffffff,
args=0x1 "", from_tty=274525132) at
../../binutils-gdb/gdb/cli/cli-decode.c:105
#6  0x1008f478 in _Z8cmd_funcP16cmd_list_elementPci (cmd=0x20111d78,
args=0x0, from_tty=1) at ../../binutils-gdb/gdb/cli/cli-decode.c:1913
#7  0x10061298 in _Z15execute_commandPci (p=0x200a9798 "kill",
from_tty=1) at ../../binutils-gdb/gdb/top.c:80
#8  0x1002fed4 in _Z15command_handlerPc (command=0x200a9798 "kill") at
../../binutils-gdb/gdb/event-top.c:577
#9  0x1003033c in _Z20command_line_handlerPc (rl=0xffffffff <error:
Cannot access memory at address 0xffffffff>)
    at ../../binutils-gdb/gdb/event-top.c:25
#10 0x1002ea40 in _ZL23gdb_rl_callback_handlerPc (rl=0x200a99a8
"kill") at ../../binutils-gdb/gdb/event-top.c:200
#11 0x100320a8 in rl_callback_read_char () at
../../binutils-gdb/readline/callback.c:220
#12 0x1002e8f0 in _ZL33gdb_rl_callback_read_char_wrapperPv
(client_data=0xffffffff) at ../../binutils-gdb/gdb/event-top.c:173
#13 0x1002f540 in _Z19stdin_event_handleriPv (error=-1,
client_data=0x200a97a8) at ../../binutils-gdb/gdb/event-top.c:505
#14 0x102af9a8 in _ZL17handle_file_eventP12file_handleri
(file_ptr=0x20142908, ready_mask=1) at
../../binutils-gdb/gdb/event-loop.c:733
#15 0x102b012c in _ZL18gdb_wait_for_eventi (block=-1) at
../../binutils-gdb/gdb/event-loop.c:859
#16 0x102b0440 in _Z16gdb_do_one_eventv.part.2 () at
../../binutils-gdb/gdb/event-loop.c:347
#17 0x102b06a0 in _Z16start_event_loopv () at
../../binutils-gdb/gdb/common/common-exceptions.h:221
#18 0x10000414 in _ZL21captured_command_loopPv (data=0xffffffff) at
../../binutils-gdb/gdb/main.c:325
#19 0x102aaf34 in _Z12catch_errorsPFiPvES_Pc11return_mask
(func=@0x200643ac: 0x100003d4 <_ZL21captured_command_loopPv>,
func_args=0x0,
    errstring=0x105963d4 <_GLOBAL__F_interpreter_p+980> "",
mask=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:236
#20 0x10001988 in _Z8gdb_mainP18captured_main_args (args=0x0) at
../../binutils-gdb/gdb/main.c:2302
#21 0x100003a4 in main (argc=-1, argv=<incomplete type>) at
../../binutils-gdb/gdb/gdb.c:32

If I "continue", I get the followings,

(top-gdb) bt
#0  0xd057a02c in pthread_kill () from /usr/lib/libpthreads.a(shr_xpg5.o)
#1  0xd057940c in _p_raise () from /usr/lib/libpthreads.a(shr_xpg5.o)
#2  0xd0123348 in raise () from /usr/lib/libc.a(shr.o)
#3  0xd018991c in abort () from /usr/lib/libc.a(shr.o)
#4  0x1001986c in uw_init_context_1 (context=0x2ff216e8,
outer_cfa=0x2ff21ae0, outer_ra=0x1001ac80
<_Unwind_Resume_or_Rethrow+212>)
    at ../../../gcc-6.1.0/libgcc/unwind-dw2.c:13
#5  0x1001a520 in _Unwind_RaiseException (exc=0x20147f78) at
../../../gcc-6.1.0/libgcc/unwind.inc:88
#6  0x1001ac80 in _Unwind_Resume_or_Rethrow (exc=0x20147f78) at
../../../gcc-6.1.0/libgcc/unwind.inc:252
#7  0x1002a138 in __cxa_rethrow () at  _start_ :118
#8  0x1001d410 in __gnu_cxx::__verbose_terminate_handler () at
../../../../gcc-6.1.0/libstdc++-v3/libsupc++/vterminate.cc:80
#9  0x1002a568 in __cxxabiv1::__terminate (handler=<incomplete type>)
at ../../../../gcc-6.1.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
#10 0x1001d2c8 in std::terminate () at  _start_ :57
#11 0x1002a8d8 in __cxa_throw (obj=<error reading variable>,
tinfo=<error reading variable>, dest=<error reading variable>) at
_start_ :87
#12 0x10030d40 in _ZL19throw_exception_cxx13gdb_exception
(exception=...) at
../../binutils-gdb/gdb/common/common-exceptions.c:16
#13 0x10030e48 in _ZL8throw_it13return_reason6errorsPKcPc
(reason=RETURN_ERROR, error=GENERIC_ERROR,
    fmt=0xffffffff <error: Cannot access memory at address
0xffffffff>, ap=0xffffffff <error: Cannot access memory at address
0xffffffff>)
    at ../../binutils-gdb/gdb/common/common-exceptions.c:317
#14 0x10031390 in _Z12throw_verror6errorsPKcPc (error=GDB_NO_ERROR,
fmt=0xffffffff <error: Cannot access memory at address 0xffffffff>,
    ap=0xffffffff <error: Cannot access memory at address 0xffffffff>)
at ../../binutils-gdb/gdb/common/common-exceptions.c:379
#15 0x1000f940 in _Z6verrorPKcPc (string=0x0, args=0xffffffff <error:
Cannot access memory at address 0xffffffff>)
    at ../../binutils-gdb/gdb/utils.c:477
#16 0x1002e6a4 in _Z5errorPKcz (fmt=0x0) at
../../binutils-gdb/gdb/common/errors.c:43
#17 0x100d90f0 in _ZL12kill_commandPci (arg=0x0, from_tty=-1) at
../../binutils-gdb/gdb/infcmd.c:2578
#18 0x1008b548 in _ZL8do_cfuncP16cmd_list_elementPci (c=0x0,
args=0xffffffff <error: Cannot access memory at address 0xffffffff>,
from_tty=-1)
    at ../../binutils-gdb/gdb/cli/cli-decode.c:105
#19 0x1008f3f8 in _Z8cmd_funcP16cmd_list_elementPci (cmd=0x20112988,
args=0x0, from_tty=1) at ../../binutils-gdb/gdb/cli/cli-decode.c:1913
#20 0x10061218 in _Z15execute_commandPci (p=0x200aa3a8 "kill",
from_tty=1) at ../../binutils-gdb/gdb/top.c:80
#21 0x1002fed4 in _Z15command_handlerPc (command=0x200aa3a8 "kill") at
../../binutils-gdb/gdb/event-top.c:577
#22 0x1003033c in _Z20command_line_handlerPc (rl=0x0) at
../../binutils-gdb/gdb/event-top.c:25
#23 0x1002ea40 in _ZL23gdb_rl_callback_handlerPc (rl=0x200aa5b8
"kill") at ../../binutils-gdb/gdb/event-top.c:200
#24 0x100320a8 in rl_callback_read_char () at
../../binutils-gdb/readline/callback.c:220
#25 0x1002e8f0 in _ZL33gdb_rl_callback_read_char_wrapperPv
(client_data=0x0) at ../../binutils-gdb/gdb/event-top.c:173
#26 0x1002f540 in _Z19stdin_event_handleriPv (error=0,
client_data=0x200aa3b8) at ../../binutils-gdb/gdb/event-top.c:505
#27 0x102af928 in _ZL17handle_file_eventP12file_handleri
(file_ptr=0x20143518, ready_mask=1) at
../../binutils-gdb/gdb/event-loop.c:733
#28 0x102b00ac in _ZL18gdb_wait_for_eventi (block=-1) at
../../binutils-gdb/gdb/event-loop.c:859
---Type <return> to continue, or q <return> to quit---
#29 0x102b03c0 in _Z16gdb_do_one_eventv.part.2 () at
../../binutils-gdb/gdb/event-loop.c:347
#30 0x102b0620 in _Z16start_event_loopv () at
../../binutils-gdb/gdb/common/common-exceptions.h:221
#31 0x10000414 in _ZL21captured_command_loopPv (data=0x0) at
../../binutils-gdb/gdb/main.c:325
#32 0x102aaeb4 in _Z12catch_errorsPFiPvES_Pc11return_mask
(func=@0x20064fc0: 0x100003d4 <_ZL21captured_command_loopPv>,
func_args=0x0,
    errstring=0x10596354 <_GLOBAL__F_interpreter_p+980> "",
mask=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:236
#33 0x10001988 in _Z8gdb_mainP18captured_main_args (args=0x0) at
../../binutils-gdb/gdb/main.c:2302
#34 0x100003a4 in main (argc=0, argv=<incomplete type>) at
../../binutils-gdb/gdb/gdb.c:32

I don't check the code carefully yet, will do it tomorrow.

-- 
Yao


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: gdb on AIX
  2005-12-20  9:11   ` Petchesi Gabriel Horatiu
@ 2005-12-20 10:45     ` Joel Brobecker
  0 siblings, 0 replies; 10+ messages in thread
From: Joel Brobecker @ 2005-12-20 10:45 UTC (permalink / raw)
  To: Petchesi Gabriel Horatiu; +Cc: gdb

> I found this in gdbgdb/config.log subdir
> ....
> configure:7550: checking for main in -lm
> configure:7606: result: no

This is incomplete. Did you get this after a first configure run,
or did you do a reconfigure. For instance, I checked in one of the
builds we have here, and I see:

    configure:7550: checking for main in -lm
    configure:7574: gcc -o conftest -g -D_LONG_LONG    conftest.c -lm   >&5
    configure:7580: $? = 0
    configure:7584: test -z
                             || test ! -s conftest.err
    configure:7587: $? = 0
    configure:7590: test -s conftest
    configure:7593: $? = 0
    configure:7606: result: yes

I do get the same result as you, however, if I do a second configure
over an already configured directory. What happens is that configure
then uses the cache instead of recomputing everything. 

The part of configure that does this checking is right after:

    # ---------------------- #
    # Checks for libraries.  # 
    # ---------------------- #
    
    # We might need to link with -lm; most simulators need it.

In particular, I see:

        else
          echo "$as_me: failed program was:" >&5
        sed 's/^/| /' conftest.$ac_ext >&5

So in your case where the result is "no", you should get two things:
The full listing of the program that configure tried to compile and
GCC failed to build, and just before that, the actual error printed
by the compiler.

Short of that, I can only suggest to dive into the configure script
and add some traces to help you find the source of your problem.

You may also try to do a 

        make LDFLAGS="-lm" 

That will just work-around your problem, but perhaps you'll be able
to get a debugger in the meantime.

-- 
Joel


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: gdb on AIX
  2005-12-19 11:19 ` Joel Brobecker
@ 2005-12-20  9:11   ` Petchesi Gabriel Horatiu
  2005-12-20 10:45     ` Joel Brobecker
  0 siblings, 1 reply; 10+ messages in thread
From: Petchesi Gabriel Horatiu @ 2005-12-20  9:11 UTC (permalink / raw)
  To: gdb

On Mon, 2005-12-19 at 15:19 +0400, Joel Brobecker wrote: 
> > gcc -g -O2      -Wl,-bbigtoc -lpthdebug  \
> >         -o gdb gdb.o libgdb.a \
> >            ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a  ../libiberty/libiberty.a     -lcurses -liconv ../libiberty/libiberty.a
> > ld: 0711-317 ERROR: Undefined symbol: .pow
> > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> > information.
> > collect2: ld returned 8 exit status
> 
> pow() is part of libm.
=====
I checked where pow is defined in /usr/lib with:

$ nm -A lib*.a | grep "\.pow"

And i found these symbol definitions:
libC.a:ansi_32.o:000000000007751c T .pow
libC.a:ansi_64.o:0000000000076964 T .pow
libC128.a:ansi_32.o:0000000000077924 T .pow
libC128.a:ansi_64.o:0000000000076e50 T .pow
libC128_r.a:ansi_32.o:0000000000077924 T .pow
libC128_r.a:ansi_64.o:0000000000076e50 T .pow
libC_r.a:ansi_32.o:000000000007751c T .pow
libbsd.a:shr.o:0000000000003a28 T .pow
libbsd_r.a:shr.o:0000000000003a28 T .pow
libdiag.a:shr.o:0000000000022cb0 T .pow
libisode.a:shr.o:0000000000030b48 T .pow
libisode.a:shr_64.o:0000000000035444 T .pow

So the function should be available from the libC.a library !?

>  On our AIX machine (5.3), configure automatically
> adds -lm to the list of libs (ie "-lcurses -lm -liconv") or somesuch.
> I think the check that adds it is:
> 
>         # We might need to link with -lm; most simulators need it.
>         AC_CHECK_LIB(m, main)
> 
> You need to search a line in your build output saying something like:
> 
>         checking for main in -lm
> And see what it answered. The answer should be "yes". If you see "no",
> then check out "config.log". This file should contain all the details.
=====
I found this in gdbgdb/config.log subdir
....
configure:7505: checking for mig
configure:7534: result: no
configure:7550: checking for main in -lm
configure:7606: result: no
configure:7622: checking for wctype
configure:7710: result: yes
....

Do you know from what package this lib is located?

I'm going to Google for it try to install and give it a try.

	gabriel

-- 
Petchesi Gabriel Horatiu
E-mail: gabi@prolix.ro


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: gdb on AIX
  2005-12-19  9:57 gdb " Petchesi Gabriel Horatiu
@ 2005-12-19 11:19 ` Joel Brobecker
  2005-12-20  9:11   ` Petchesi Gabriel Horatiu
  0 siblings, 1 reply; 10+ messages in thread
From: Joel Brobecker @ 2005-12-19 11:19 UTC (permalink / raw)
  To: Petchesi Gabriel Horatiu; +Cc: gdb

> gcc -g -O2      -Wl,-bbigtoc -lpthdebug  \
>         -o gdb gdb.o libgdb.a \
>            ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a  ../libiberty/libiberty.a     -lcurses -liconv ../libiberty/libiberty.a
> ld: 0711-317 ERROR: Undefined symbol: .pow
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information.
> collect2: ld returned 8 exit status

pow() is part of libm. On our AIX machine (5.3), configure automatically
adds -lm to the list of libs (ie "-lcurses -lm -liconv") or somesuch.
I think the check that adds it is:

        # We might need to link with -lm; most simulators need it.
        AC_CHECK_LIB(m, main)

You need to search a line in your build output saying something like:

        checking for main in -lm

And see what it answered. The answer should be "yes". If you see "no",
then check out "config.log". This file should contain all the details.

-- 
Joel


^ permalink raw reply	[flat|nested] 10+ messages in thread

* gdb on AIX
@ 2005-12-19  9:57 Petchesi Gabriel Horatiu
  2005-12-19 11:19 ` Joel Brobecker
  0 siblings, 1 reply; 10+ messages in thread
From: Petchesi Gabriel Horatiu @ 2005-12-19  9:57 UTC (permalink / raw)
  To: gdb

Hi!

I'm having the following problems with gdb on AIX 5.2, 32 bit, Power PC
architecture:

1. Debugging static variables with gdb 6.0 
This problem problem generated more grief than anything else. 
If in a program i have a static global variable I'm not able to monitor
the value. The tracing/monitoring of local variables works fine.
======================================================================
$ more main.c
#include <stdio.h>

static int32_t i = 0;

int main(int argc, char **argv)
{
  while (1)
  {
    printf("Value %d\n", i);
    sleep(2);
    i++;
  }
}

$ make
gcc -c -o main.o -ggdb3    main.c
gcc -o bb -ggdb3   main.o

$ gdb ./bb
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "powerpc-ibm-aix5.1.0.0"...
(gdb) break main.c:11
Breakpoint 1 at 0x10000394: file main.c, line 11.
(gdb) run
Starting program: /home/gabi/test_appz/bluebird/bb
Value 0

Breakpoint 1, main (argc=1, argv=0x2ff228d4) at main.c:11
11          i++;
(gdb) print i
No symbol "i" in current context.
(gdb) display i
No symbol "i" in current context.
(gdb) next
9           printf("Value %d\n", i);
(gdb) next
Value 1
======================================================================
I noticed 2 different behaviors for these type of variables in 2
different programs:
a. The "No symbol in current context" message.
b. Wrong value printed out. The symbol is found but the value that is
printed out is not correct.
Is this a known issue or am I doing something wrong?

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

2. Compilation of gdb 6.4 on AIX 5.2
I try to solve the problems noticed at #1 by trying out the latest
version of gdb (6.4) on AIX. I try to compile it with the following:

$ gcc -v
Reading specs
from /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/specs
Configured with: ../configure --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --disable-nls --enable-languages=c,c++
--prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.2.0.0
Thread model: aix
gcc version 3.3.2

The compilation stops at the final stage of link-editing:
======================================================================================
config.status: creating Makefile
make[2]: Entering directory `/home/gabi/temp/gdb-6.4/sim'
make[3]: Entering directory `/home/gabi/temp/gdb-6.4/sim/ppc'
CONFIG_FILES= CONFIG_HEADERS=config.h:config.in /bin/sh ./config.status
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default commands
# The first for loop is to remove duplicates.
f=""; \
for i in hw_cpu.c hw_memory.c hw_nvram.c hw_iobus.c hw_htab.c hw_disk.c
hw_trace.c hw_register.c hw_vm.c hw_init.c hw_core.c hw_pal.c hw_com.c
hw_eeprom.c hw_opic.c hw_glue.c hw_phb.c hw_ide.c ; do \
  case " $f " in \
    *" $i "*) ;; \
    *) f="$f $i" ;; \
  esac ; \
done ; \
for hw in $f ; do echo $hw ; done \
| sed -e 's/^.*\(hw_.*\)\.c/\1/' \
        -e 's/^/extern const device_descriptor /' \
        -e 's/$/_device_descriptor\[\];/' \
        > tmp-hw.h
f=""; \
for i in hw_cpu.c hw_memory.c hw_nvram.c hw_iobus.c hw_htab.c hw_disk.c
hw_trace.c hw_register.c hw_vm.c hw_init.c hw_core.c hw_pal.c hw_com.c
hw_eeprom.c hw_opic.c hw_glue.c hw_phb.c hw_ide.c ; do \
  case " $f " in \
    *" $i "*) ;; \
    *) f="$f $i" ;; \
  esac ; \
done ; \
for hw in $f ; do echo $hw ; done \
| sed -e 's/^.*\(hw_.*\)\.c/\1/' \
        -e 's/^/    /' \
        -e 's/$/_device_descriptor,/' \
        > tmp-hw.c
/bin/sh ../.././sim/ppc/../../move-if-change tmp-hw.h hw.h
/bin/sh ../.././sim/ppc/../../move-if-change tmp-hw.c hw.c
touch tmp-hw
# The first for loop is to remove duplicates.
f=""; \
for i in pk_disklabel.c ; do \
  case " $f " in \
    *" $i "*) ;; \
    *) f="$f $i" ;; \
  esac ; \
done ; \
for pk in $f ; do echo $pk ; done \
| sed -e 's/^.*pk_\(.*\)\.c/\1/' \
        -e 's/^/extern package_create_instance_callback pk_/' \
        -e 's/$/_create_instance;/' \
        > tmp-pk.h
/bin/sh ../.././sim/ppc/../../move-if-change tmp-pk.h pk.h
touch tmp-pk
sed -n -e '/^#define HAVE_/s/ 1$/",/' -e '/^#define HAVE_/s//"HAVE_/p' <
config.h > tmp-defines.h
/bin/sh ../.././sim/ppc/../../move-if-change tmp-defines.h defines.h
touch tmp-defines
gcc  -I. -I../common -I../.././sim/ppc/../common -o
gentmap ../common/gentmap.c
rm -f tmp-vals.h
./gentmap -h > tmp-vals.h
/bin/sh ../.././sim/ppc/../../move-if-change tmp-vals.h targ-vals.h
rm -f tmp-map.c
./gentmap -c > tmp-map.c
/bin/sh ../.././sim/ppc/../../move-if-change tmp-map.c targ-map.c
gcc -c -g -O2  -DDEFAULT_INLINE=PSIM_INLINE_LOCALS
-DWITH_HOST_BYTE_ORDER=BIG_ENDIAN -DWITH_SMP=5
-DHAVE_TERMIO_STRUCTURE -DHAVE_TERMIO_CLINE -DHAVE_DEVZERO     -I.
-I../.././sim/ppc -I../.././sim/ppc/../../include -I../../bfd
-I../.././sim/ppc/../../bfd -I../../gdb -I../.././sim/ppc/../../gdb
-I../.././sim/ppc/../../gdb/config -I../../intl
-I../.././sim/ppc/../../intl -DHAVE_COMMON_FPU -I../common
-I../.././sim/ppc/../common '-DOPCODE_RULES="dc-complex"'
'-DIGEN_FLAGS=" -E  -F 32,f,o -CSRI 1024 -N 5 "' '-DDGEN_FLAGS=""'
options.c
rm -f libsim.a
ar rc libsim.a debug.o filter_filename.o bits.o sim-endian.o os_emul.o
emul_generic.o emul_bugapi.o emul_chirp.o emul_netbsd.o emul_unix.o
registers.o vm.o corefile.o model.o spreg.o cpu.o interrupts.o events.o
cap.o device.o tree.o device_table.o itable.o mon.o icache.o semantics.o
idecode.o support.o sim-fpu.o psim.o pk_disklabel.o hw_cpu.o hw_memory.o
hw_nvram.o hw_iobus.o hw_htab.o hw_disk.o hw_trace.o hw_register.o
hw_vm.o hw_init.o hw_core.o hw_pal.o hw_com.o hw_eeprom.o hw_opic.o
hw_glue.o hw_phb.o hw_ide.o options.o gdb-sim.o sim_calls.o callback.o
targ-map.o
ranlib libsim.a
gcc -g -O2    -o psim main.o
libsim.a ../../bfd/libbfd.a  ../../libiberty/libiberty.a
rm -f run
ln psim run
make[3]: Leaving directory `/home/gabi/temp/gdb-6.4/sim/ppc'
make[3]: Entering directory `/home/gabi/temp/gdb-6.4/sim/common'
make[3]: Nothing to be done for `default'.
make[3]: Leaving directory `/home/gabi/temp/gdb-6.4/sim/common'
make[2]: Leaving directory `/home/gabi/temp/gdb-6.4/sim'
make[2]: Entering directory `/home/gabi/temp/gdb-6.4/gdb'
CONFIG_HEADERS=config.h:config.in /bin/sh config.status
config.status: creating Makefile
config.status: creating .gdbinit
config.status: creating config.h
config.status: config.h is unchanged
config.status: linking .././gdb/config/rs6000/tm-rs6000.h to tm.h
config.status: linking .././gdb/config/powerpc/nm-aix.h to nm.h
config.status: executing default commands
rm -f version.c-tmp version.c
echo '#include "version.h"' >> version.c-tmp
echo 'const char version[] = "'"`sed q .././gdb/version.in`"'";' >>
version.c-tmp
echo 'const char host_name[] = "powerpc-ibm-aix5.2.0.0";' >>
version.c-tmp
echo 'const char target_name[] = "powerpc-ibm-aix5.2.0.0";' >>
version.c-tmp
mv version.c-tmp version.c
gcc -c -g -O2     -I. -I.././gdb -I.././gdb/config
-DLOCALEDIR="\"/opt/gdb_6.4/share/locale\"" -DHAVE_CONFIG_H
-I.././gdb/../include/opcode -I.././gdb/../readline/.. -I../bfd
-I.././gdb/../bfd -I.././gdb/../include -I../intl -I.././gdb/../intl
-DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs
-Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral
-Wunused-label -Wunused-function -Wuninitialized  version.c
Making init.c
gcc -c -g -O2     -I. -I.././gdb -I.././gdb/config
-DLOCALEDIR="\"/opt/gdb_6.4/share/locale\"" -DHAVE_CONFIG_H
-I.././gdb/../include/opcode -I.././gdb/../readline/.. -I../bfd
-I.././gdb/../bfd -I.././gdb/../include -I../intl -I.././gdb/../intl
-DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs
-Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral
-Wunused-label -Wunused-function -Wuninitialized  init.c
rm -f libgdb.a
ar q libgdb.a rs6000-tdep.o xcoffread.o ppc-sysv-tdep.o solib.o
solib-svr4.o ser-base.o ser-unix.o ser-pipe.o ser-tcp.o fork-child.o
infptrace.o inftarg.o corelow.o rs6000-nat.o xcoffread.o xcoffsolib.o
remote.o dcache.o remote-utils.o tracepoint.o ax-general.o ax-gdb.o
remote-fileio.o  cli-dump.o cli-decode.o cli-script.o cli-cmds.o
cli-setshow.o cli-utils.o cli-logging.o cli-interp.o mi-out.o
mi-console.o mi-cmds.o mi-cmd-env.o mi-cmd-var.o mi-cmd-break.o
mi-cmd-stack.o mi-cmd-file.o mi-cmd-disas.o mi-symbol-cmds.o mi-interp.o
mi-main.o mi-parse.o mi-getopt.o mi-common.o aix-thread.o tui-command.o
tui-data.o tui-disasm.o tui-file.o tui.o tui-hooks.o tui-interp.o
tui-io.o tui-layout.o tui-out.o tui-regs.o tui-source.o tui-stack.o
tui-win.o tui-windata.o tui-wingeneral.o tui-winsource.o c-exp.o
cp-name-parser.o objc-exp.o ada-exp.o jv-exp.o f-exp.o m2-exp.o p-exp.o
version.o annotate.o auxv.o bfd-target.o blockframe.o breakpoint.o
findvar.o regcache.o charset.o disasm.o dummy-frame.o source.o value.o
eval.o valops.o valarith.o valprint.o printcmd.o block.o symtab.o
symfile.o symmisc.o linespec.o dictionary.o infcall.o infcmd.o infrun.o
expprint.o environ.o stack.o thread.o exceptions.o inf-child.o interps.o
main.o macrotab.o macrocmd.o macroexp.o macroscope.o event-loop.o
event-top.o inf-loop.o completer.o gdbarch.o arch-utils.o gdbtypes.o
osabi.o copying.o memattr.o mem-break.o target.o parse.o language.o
buildsym.o std-regs.o signals.o kod.o kod-cisco.o gdb-events.o exec.o
bcache.o objfiles.o observer.o minsyms.o maint.o demangle.o dbxread.o
coffread.o coff-pe-read.o elfread.o dwarfread.o dwarf2read.o mipsread.o
stabsread.o corefile.o dwarf2expr.o dwarf2loc.o dwarf2-frame.o
ada-lang.o c-lang.o f-lang.o objc-lang.o ui-out.o cli-out.o varobj.o
wrapper.o jv-lang.o jv-valprint.o jv-typeprint.o m2-lang.o p-lang.o
p-typeprint.o p-valprint.o scm-exp.o scm-lang.o scm-valprint.o
sentinel-frame.o complaints.o typeprint.o ada-typeprint.o c-typeprint.o
f-typeprint.o m2-typeprint.o ada-valprint.o c-valprint.o cp-valprint.o
f-valprint.o m2-valprint.o nlmread.o serial.o mdebugread.o top.o utils.o
ui-file.o user-regs.o frame.o frame-unwind.o doublest.o frame-base.o
gnu-v2-abi.o gnu-v3-abi.o hpacc-abi.o cp-abi.o cp-support.o
cp-namespace.o reggroups.o regset.o trad-frame.o tramp-frame.o solib.o
solib-null.o inflow.o    init.o
ranlib libgdb.a
rm -f gdb
gcc -g -O2      -Wl,-bbigtoc -lpthdebug  \
        -o gdb gdb.o libgdb.a \
           ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a  ../libiberty/libiberty.a     -lcurses -liconv ../libiberty/libiberty.a
ld: 0711-317 ERROR: Undefined symbol: .pow
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
collect2: ld returned 8 exit status
make[2]: *** [gdb] Error 1
make[2]: Leaving directory `/home/gabi/temp/gdb-6.4/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/home/gabi/temp/gdb-6.4'
make: *** [all] Error 2
======================================================================================
Is this a known issue any workarounds?
Does one of the releases 6.0 -> 6.4 solve the problem described at #1.

I tried also compiling 6.3 from sources but it stops at a previous step
(some dependency in gettext if i remember correctly).

	gabriel

-- 
Petchesi Gabriel Horatiu
E-mail: gabi@prolix.ro


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2016-11-14 22:16 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-14 15:51 GDB on AIX Yao Qi
2016-11-14 16:17 ` David Edelsohn
2016-11-14 17:18 ` Pedro Alves
2016-11-14 17:35   ` David Edelsohn
2016-11-14 17:44     ` Pedro Alves
2016-11-14 22:16   ` Yao Qi
  -- strict thread matches above, loose matches on Subject: below --
2005-12-19  9:57 gdb " Petchesi Gabriel Horatiu
2005-12-19 11:19 ` Joel Brobecker
2005-12-20  9:11   ` Petchesi Gabriel Horatiu
2005-12-20 10:45     ` Joel Brobecker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox