gdb procfs 64bit Solaris problem

gdb procfs 64bit Solaris problem

[Stefano Frullani - NOSPAM]

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



.

Re: gdb procfs 64bit Solaris problem

[M.M. Kettenis]

"Stefano Frullani - NOSPAM"  <stefanoDOTfrullaniATfrumarDOTit@frumar.it> wrote:

> 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.

Did yoy compile gdb as a 64-bit executable?  To check run file(1) on
your gdb executable.  If not please try reconfiguring and rebuilding
gdb with the environment variable CC set to "gcc -m64".

Mark

Re: gdb procfs 64bit Solaris problem

[Stefano Frullani]

>
> Did yoy compile gdb as a 64-bit executable?  To check run file(1) on
> your gdb executable.  If not please try reconfiguring and rebuilding
> gdb with the environment variable CC set to "gcc -m64".
>
> Mark
>

Thanks Mark,
recompiling gdb with:

CC=gcc
CFLAGS=-m64
./configure sparcv9-sun-solaris9

has solved the issue.

Many Thanks.
Stefano Frullani





.

Re: gdb procfs 64bit Solaris problem

[Daniel Jacobowitz]

On Thu, Apr 21, 2005 at 04:31:03PM +0200, Stefano Frullani wrote:
> 
> 
> 
> >
> > Did yoy compile gdb as a 64-bit executable?  To check run file(1) on
> > your gdb executable.  If not please try reconfiguring and rebuilding
> > gdb with the environment variable CC set to "gcc -m64".
> >
> > Mark

Hi Mark,

This seems to be an incredibly frequently recurring problem for
sparc-solaris users.  Can we make GDB detect the problem?  I would
suggest making configury default to 64-bit for sparcv9/sparc64, but
that's not appropriate for gcc or binutils or other toplevel projects,
probably.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb procfs 64bit Solaris problem

[Stefano Frullani - NOSPAM]

>
> Hi Mark,
>
> This seems to be an incredibly frequently recurring problem for
> sparc-solaris users.  Can we make GDB detect the problem?  I would
> suggest making configury default to 64-bit for sparcv9/sparc64, but
> that's not appropriate for gcc or binutils or other toplevel projects,
> probably.
>
> --
> Daniel Jacobowitz
> CodeSourcery, LLC
>
>
> .
>
>

Maybe a note in README will be helpfull.

Bye
Stefano


.

Re: gdb procfs 64bit Solaris problem

[Eli Zaretskii]

> Date: Thu, 21 Apr 2005 10:34:57 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: "M.M. Kettenis" <m.m.kettenis@alumnus.utwente.nl>,
> 	Stefano Frullani - NOSPAM <stefanodotfrullaniatfrumardotit@frumar.it>,
> 	gdb@sources.redhat.com
> 
> This seems to be an incredibly frequently recurring problem for
> sparc-solaris users.  Can we make GDB detect the problem?

I second the request.

Re: gdb procfs 64bit Solaris problem

[Mark Kettenis]

   Date: Thu, 21 Apr 2005 10:34:57 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Thu, Apr 21, 2005 at 04:31:03PM +0200, Stefano Frullani wrote:
   > 
   > > Did yoy compile gdb as a 64-bit executable?  To check run file(1) on
   > > your gdb executable.  If not please try reconfiguring and rebuilding
   > > gdb with the environment variable CC set to "gcc -m64".
   > >
   > > Mark

   Hi Mark,

   This seems to be an incredibly frequently recurring problem for
   sparc-solaris users.  Can we make GDB detect the problem?  I would
   suggest making configury default to 64-bit for sparcv9/sparc64, but
   that's not appropriate for gcc or binutils or other toplevel projects,
   probably.

That's seems like a good idea.  Have to think a bit though where to
stick this warning, but I'll find the proper spot.

Mark

Re: gdb procfs 64bit Solaris problem

[Daniel Jacobowitz]

On Thu, Apr 21, 2005 at 09:26:41PM +0200, Mark Kettenis wrote:
> That's seems like a good idea.  Have to think a bit though where to
> stick this warning, but I'll find the proper spot.

Thanks!

-- 
Daniel Jacobowitz
CodeSourcery, LLC