Compiling on AIX 5.3 with xlC

Hi,

is compiling on AIX 5.3 with xlC supported?

I see several errors for example:

1. gdb-6.7/sim/ppc/words.h  has no definition of natural64
for other 
configurations than __GLIBC__ and _MSC_VER.

2. The following command is executed after a make restart: 

cc -g -I. -I../../../gdb-6.7/sim/ppc
-I../../../gdb-6.7/sim/ppc/../../include -I../../bfd
-I../../../gdb-6.7/
sim/ppc/../../bfd -I../../gdb
-I../../../gdb-6.7/sim/ppc/../../gdb 
-I../../../gdb-6.7/sim/ppc/../../gdb/config  -I. -I../common
-I../../../gdb-6.7/sim
/ppc/../common -o gentmap

Without any input files there is nothing to produce.

Christoph

On Thu, Oct 18, 2007 at 01:30:49PM +0200, Christoph
Bartoschek wrote:
> Hi,
> 
> is compiling on AIX 5.3 with xlC supported?

I do not know of anyone who has done it.

> 1. gdb-6.7/sim/ppc/words.h  has no definition of
natural64 for other 
> configurations than __GLIBC__ and _MSC_VER.
> 
> 2. The following command is executed after a make
restart: 
> 
> cc -g -I. -I../../../gdb-6.7/sim/ppc
-I../../../gdb-6.7/sim/ppc/../../include -I../../bfd
-I../../../gdb-6.7/
> sim/ppc/../../bfd -I../../gdb
-I../../../gdb-6.7/sim/ppc/../../gdb 
-I../../../gdb-6.7/sim/ppc/../../gdb/config  -I. -I../common
-I../../../gdb-6.7/sim
> /ppc/../common -o gentmap
> 
> Without any input files there is nothing to produce.

--disable-sim may help.  The second item is probably a GNU
make / AIX
make problem.

-- 
Daniel Jacobowitz
CodeSourcery

Am Donnerstag, 18. Oktober 2007 schrieb Daniel Jacobowitz:

> --disable-sim may help.  The second item is probably a
GNU make / AIX
> make problem.

Thanks, I have used --disable-sim and used gmake instead of
make. Now the 
build succeded and it seems as if gdb works.

Christoph

Am Donnerstag, 18. Oktober 2007 schrieb Christoph
Bartoschek:
> Am Donnerstag, 18. Oktober 2007 schrieb Daniel
Jacobowitz:
> > --disable-sim may help.  The second item is
probably a GNU make / AIX
> > make problem.
>
> Thanks, I have used --disable-sim and used gmake
instead of make. Now the
> build succeded and it seems as if gdb works.

I claimed success too early. I am not able to attach to a
process. 

Christoph

> I claimed success too early. I am not able to attach to
a process. 

That's strange. I don't have any problems:

    (gdb) attach  700422
    Attaching to program: /[...]/foo, process 700422
    0xd0234e94 in nsleep () from /usr/lib/libc.a(shr.o)
    (gdb) bt
    #0  0xd0234e94 in nsleep () from /usr/lib/libc.a(shr.o)
    #1  0xd026759c in nanosleep () from
/usr/lib/libc.a(shr.o)
    #2  0x100174d4 in system.os_primitives.timed_delay ()
    #3  0x100211ac in ada.calendar.delays.timed_delay_nt ()
    #4  0x100210d4 in ada.calendar.delays.delay_for ()
    #5  0x1002d3ec in pck.wait_for_debugger () at
pck.adb:11
    #6  0x1002da58 in foo () at foo.adb:15

Something must have happened during the build. Are you able
to
debug GDB?

-- 
Joel

Am Donnerstag, 18. Oktober 2007 schrieb Joel Brobecker:
> > I claimed success too early. I am not able to
attach to a process.
>
> That's strange. I don't have any problems:
>
>     (gdb) attach  700422
>     Attaching to program: /[...]/foo, process 700422
>     0xd0234e94 in nsleep () from
/usr/lib/libc.a(shr.o)
>     (gdb) bt
>     #0  0xd0234e94 in nsleep () from
/usr/lib/libc.a(shr.o)
>     #1  0xd026759c in nanosleep () from
/usr/lib/libc.a(shr.o)
>     #2  0x100174d4 in system.os_primitives.timed_delay
()
>     #3  0x100211ac in
ada.calendar.delays.timed_delay_nt ()
>     #4  0x100210d4 in ada.calendar.delays.delay_for ()
>     #5  0x1002d3ec in pck.wait_for_debugger () at
pck.adb:11
>     #6  0x1002da58 in foo () at foo.adb:15
>
> Something must have happened during the build. Are you
able to
> debug GDB?

I did not make my point clear. I am able to attach but I do
not get any 
backtrace. Here is my log:

bartoschduco:/fs/data/bartosch/work/12.1aktuell>gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/l
icenses/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-aix5.3.0.0".
(gdb) attach 98248
Attaching to process 98248
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or
n) y
Detaching from program: , process 98248
bartoschduco:/fs/data/bartosch/work/12.1aktuell> 


How did you compile your GDB with xlc? Did you use the same

settings --disable-sim?

Christoph

I forgot to answer to your question. 

I have the same effects when I attach to a gdb process. 

Starting a process within gdb works and I get meaningful
tracebacks.

> How did you compile your GDB with xlc? Did you use the
same 
> settings --disable-sim?

I did NOT compile GDB with xlc, I used GCC. I should have
clarified
this in my first message. I don't have access to xlc.

-- 
Joel

> bartoschduco:/fs/data/bartosch/work/12.1aktuell>gdb
> GNU gdb 6.7
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/l
icenses/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-aix5.3.0.0".
> (gdb) attach 98248
> Attaching to process 98248
> 0x00000000 in ?? ()

Hmmm, that reminds me of a limitation in AIX. I just found
this:

  /* According to ptrace(2), ptrace may fail with EPERM if
"the
     Identifier parameter corresponds to a kernel thread
which is
     stopped in kernel mode and whose computational state
cannot be
     read or written."  This happens quite often with
register reads.  */

But I've only observed this when switching to a different
thread.
Perhaps it's what is happening to you too.

What happens if you run GDB with

        (gdb) set debug aix-thread

before you attach?

-- 
Joel

Am Donnerstag, 18. Oktober 2007 schrieb Joel Brobecker:

> What happens if you run GDB with
>
>         (gdb) set debug aix-thread
>
> before you attach?

Nothing different than in the other tests.

But you mentioned ptrace. I've seen some warnings related to
the arguments of 
ptrace during compiling. If I remember correctly there has
been a 32bit/64bit 
mismatch of the type a pointer points to.

Christoph