From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27844 invoked by alias); 13 Feb 2002 07:25:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27770 invoked from network); 13 Feb 2002 07:25:33 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 Feb 2002 07:25:33 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16atnH-0005Nz-00; Wed, 13 Feb 2002 02:25:31 -0500 Date: Tue, 12 Feb 2002 23:25:00 -0000 From: Daniel Jacobowitz To: "Martin M. Hunt" Cc: David Jones , gdb_list Subject: Re: gdbserver error (getprotobyname) Message-ID: <20020213022531.A20603@nevyn.them.org> Mail-Followup-To: "Martin M. Hunt" , David Jones , gdb_list References: <20020213064037.92526.qmail@web13703.mail.yahoo.com> <200202130709.XAA19969@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202130709.XAA19969@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00203.txt.bz2 On Tue, Feb 12, 2002 at 11:09:34PM -0800, Martin M. Hunt wrote: > David, > > I don't know what causes this; perhaps a problem with the getprotobyname() > function on your board. > > You could try bypassing that function call. In this context it has no useful > function anyway. I don't know which sources you have, but try this patch > or something similar. This patch should -absolutely- be applied. Calling getprotobyname() loads NSS on Linux; trying to debug dynamic linking with it, which I've had to do four times now, is quite frustrating. Thanks for reminding me :) > > Index: remote-utils.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbserver/remote-utils.c,v > retrieving revision 1.7 > diff -u -p -r1.7 remote-utils.c > --- remote-utils.c 2001/07/12 21:04:35 1.7 > +++ remote-utils.c 2002/02/13 06:59:20 > @@ -106,7 +106,6 @@ remote_open (char *name) > int port; > struct sockaddr_in sockaddr; > int tmp; > - struct protoent *protoent; > int tmp_desc; > > port_str = strchr (name, ':'); > @@ -135,10 +134,6 @@ remote_open (char *name) > if (remote_desc == -1) > perror_with_name ("Accept failed"); > > - protoent = getprotobyname ("tcp"); > - if (!protoent) > - perror_with_name ("getprotobyname"); > - > /* Enable TCP keep alive process. */ > tmp = 1; > setsockopt (tmp_desc, SOL_SOCKET, SO_KEEPALIVE, (char *) &tmp, sizeof (tmp)); > @@ -146,7 +141,7 @@ remote_open (char *name) > /* Tell TCP not to delay small packets. This greatly speeds up > interactive response. */ > tmp = 1; > - setsockopt (remote_desc, protoent->p_proto, TCP_NODELAY, > + setsockopt (remote_desc, IPPROTO_TCP, TCP_NODELAY, > (char *) &tmp, sizeof (tmp)); > > close (tmp_desc); /* No longer need this */ > > -- > Martin Hunt > GDB Engineer > Red Hat, Inc. > > On Tuesday 12 February 2002 10:40 pm, David Jones wrote: > > Hi, > > I am using gdbserver on a StrongArm board compiled > > for arm-linux. On my Linux x86 host I am running > > gdb compiled to debug an arm-linux target. Thanks > > to Bill Gatliff for helping me out with this. > > > > I can successfully debug a program if I use the serial > > port between the host and the target. This is great! > > > > However when I try to use a network connection I get > > the following error: (below is a trace of my commands) > > > > (target output) > > ---------------------------------------------------- > > # ./arm-linux-gdbserver davesplace:90 hello > > Process hello created; pid = 180 > > getprotobyname: No such file or directory. > > Exiting > > > > (host output) > > (gdb) target remote tuxscreen:90 > > Remote debugging using tuxscreen:90 > > Couldn't establish connection to remote target > > Remote communication error: Connection reset by peer. > > (gdb) > > # > > ---------------------------------------------------- > > > > Has anyone seen this type of error (i.e. getprotobyname)? > > > > > > I start the gdbserver first as recommended by the GDB documentation. > > > > man getprotobyname shows: > > The getprotobyname() function returns a protoent structure for the line > > from /etc/protocols that matches the protocol name name. > > > > The /etc/protocols file is present on my StrongArm target. > > > > # more /etc/protocols > > # /etc/protocols: > > # $Id: protocols,v 1.1.1.1 2001/09/12 19:03:24 andersee Exp $ > > # > > # Internet (IP) protocols > > # > > # from: @(#)protocols 5.1 (Berkeley) 4/17/89 > > # > > # Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992). > > > > ip 0 IP # internet protocol, pseudo protocol number > > icmp 1 ICMP # internet control message protocol > > igmp 2 IGMP # Internet Group Management > > ggp 3 GGP # gateway-gateway protocol > > ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'') > > st 5 ST # ST datagram mode > > tcp 6 TCP # transmission control protocol > > egp 8 EGP # exterior gateway protocol > > pup 12 PUP # PARC universal packet protocol > > udp 17 UDP # user datagram protocol > > hmp 20 HMP # host monitoring protocol > > xns-idp 22 XNS-IDP # Xerox NS IDP > > rdp 27 RDP # "reliable datagram" protocol > > iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4 > > xtp 36 XTP # Xpress Tranfer Protocol > > ddp 37 DDP # Datagram Delivery Protocol > > idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport > > rspf 73 RSPF #Radio Shortest Path First. > > vmtp 81 VMTP # Versatile Message Transport > > ospf 89 OSPFIGP # Open Shortest Path First IGP > > ipip 94 IPIP # Yet Another IP encapsulation > > encap 98 ENCAP # Yet Another IP encapsulation > > # > > > > > > By the way my StrongArm is a tuxscreen. (see www.tuxscreen.net) > > > > David > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer