gdb procfs 64bit Solaris problem

["Stefano Frullani - NOSPAM" <stefanoDOTfrullaniATfrumarDOTit at frumar dot it>]

Hi all,
I am not able to debug a simple program :


{stefano}puma:/home/stefano/temp cat ste.c
#include <stdio.h>

int main()
{
printf("Hello world\n");
return(0);
}
{stefano}puma:/home/stefano/temp gcc -m64 -g -o ste ste.c

The environnement is Sun Sparc Solaris 2.8 (Latest patch cluster). Gcc is
3.2.3. Gdb is 6.3 built from tarball.


{stefano}puma:/home/stefano/temp gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.3/specs
Configured with: ../configure --disable-nls --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 3.2.3

{stefano}puma:/home/stefano/temp gdb -v
GNU gdb 6.3
Copyright 2004 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 "sparcv9-sun-solaris2".

When I start debugging process I get:


{stefano}puma:/home/stefano/temp truss -o /tmp/truss.out -fea -wall -rall
gdb ste
GNU gdb 6.3
Copyright 2004 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 "sparcv9-sun-solaris2"...
(gdb) run
Starting program: /home/stefano/temp/ste
procfs: target_wait (wait_for_stop) line 3953, /proc/16548: Value too
large for defined data type.
(gdb) quit
The program is running.  Exit anyway? (y or n) y


Taking a look on the trace generated via truss comand :

....
....
....
16497:  open("/proc/16548", O_RDWR)                     = 6
16497:  ioctl(6, PIOCSTATUS, 0x003124B8)                = 0
16497:  ioctl(6, PIOCGTRACE, 0x0029D938)                = 0
16497:  ioctl(6, PIOCGHOLD, 0x0029D928)                 = 0
16497:  ioctl(6, PIOCGFAULT, 0x0029D948)                = 0
16497:  ioctl(6, PIOCGENTRY, 0x0029D958)                = 0
16497:  ioctl(6, PIOCGEXIT, 0x0029D998)                 = 0
16497:  sysconfig(_CONFIG_SIGRT_MIN)                    = 38
....
....
....
16497:  ioctl(6, PIOCRUN, 0xFFBEDA70)                   = 0
16497:  ioctl(6, PIOCSTATUS, 0x003124B8)                = 0
16497:  ioctl(6, PIOCWSTOP, 0x003124B8)                 Err#79 EOVERFLOW
16497:  sigaction(SIGTTOU, 0xFFBED560, 0xFFBED5E0)      = 0
....
....
....


This is the code portion from procfs.c :


  3930        if (!(proc_flags (pi) & (PR_STOPPED | PR_ISTOP)) &&
  3931            !proc_wait_for_stop (pi))
  3932          {
  3933            /* wait_for_stop failed: has the child terminated? */
  3934            if (errno == ENOENT)
  3935              {
  3936                int wait_retval;
  3937
  3938                /* /proc file not found; presumably child has
terminated. */
  3939                wait_retval = wait (&wstat); /* "wait" for the
child's exit  */
  3940
  3941                if (wait_retval != PIDGET (inferior_ptid)) /* wrong
child? */
  3942                  error ("procfs: couldn't stop process %d: wait
returned %d\n",
  3943                         PIDGET (inferior_ptid), wait_retval);
  3944                /* FIXME: might I not just use waitpid?
  3945                   Or try find_procinfo to see if I know about this
child? */
  3946                retval = pid_to_ptid (wait_retval);
  3947              }
  3948            else if (errno == EINTR)
  3949              goto wait_again;
  3950            else
  3951              {
  3952                /* Unknown error from wait_for_stop. */
  3953                proc_error (pi, "target_wait (wait_for_stop)",
__LINE__);
  3954              }
  3955          }
  3956        else

It seems that process cannot be stopped.

Debugging 32bit compile works fine.

I have searched on mailing lists but I was not able to find a way to solve
this.

Any hint would be appreciated.



Stefano Frullani



.