Re: [PATCH RFA] solib.c

[Jim Blandy <jimb@zwingli.cygnus.com>]

This looks good.

I have only one request: the code which scans an array of
section_table entries and fills in a struct section_addr_info is
hardly specific to shared libraries.  Could you turn it into a
function, put it in symfile.c, and just call it from solib.c?  I guess
you'll need a corresponding cleanup function to free the names.

If that works out, go ahead and commit the patch.  If turns out not to
be a good idea, let me know.


> The changes below are motivated by the desire to have correct section
> addresses stored in the obj_section structs (for shared objects) found
> via the object_files list.
> 
> More information regarding this issue may be found at
> 
>     http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00681.html .
> 
> There was also a patch appended to the above message.  I hereby
> withdraw that patch from consideration.
> 
> Note that MAX_SECTIONS has been increased to 30 (from 12).  The reason
> for this is that 12 was much too small.  So how did I arrive at 30?  I
> counted the number of special sections documented in my (now rather
> old) System V ABI book and counted 24.  I added on six more for good
> measure (to accomodate architecture specific sections.)
> 
> 	* solib.c (symbol_add_stub): Make symbol_file_add() aware of
> 	all section addresses, not just .text.
> 	* symtab.h (MAX_SECTIONS): Increase to 30.
> 
> Index: solib.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/solib.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 solib.c
> --- solib.c	2000/03/15 16:55:07	1.3
> +++ solib.c	2000/03/16 19:34:40
> @@ -1182,12 +1182,37 @@ symbol_add_stub (arg)
>  
>    {
>      struct section_addr_info section_addrs;
> +    struct section_table *stp;
> +    struct cleanup *old_chain;
> +    int oidx;
>  
>      memset (&section_addrs, 0, sizeof (section_addrs));
>      section_addrs.text_addr = text_addr;
>  
> +    old_chain = make_cleanup (null_cleanup, 0);
> +
> +    for (stp = so->sections, oidx = 0; stp != so->sections_end; stp++)
> +      {
> +	if (strcmp (stp->the_bfd_section->name, ".data") == 0)
> +	  section_addrs.data_addr = stp->addr;
> +	else if (strcmp (stp->the_bfd_section->name, ".bss") == 0)
> +	  section_addrs.bss_addr = stp->addr;
> +
> +	if (stp->the_bfd_section->flags & (SEC_ALLOC | SEC_LOAD)
> +	         &&  oidx < MAX_SECTIONS)
> +	  {
> +	    section_addrs.other[oidx].addr = stp->addr;
> +	    section_addrs.other[oidx].name = 
> +	      xstrdup (stp->the_bfd_section->name);
> +	    make_cleanup (free, section_addrs.other[oidx].name);
> +	    section_addrs.other[oidx].sectindex = stp->the_bfd_section->index;
> +	    oidx++;
> +	  }
> +      }
> +
>      so->objfile = symbol_file_add (so->so_name, so->from_tty,
>  				   &section_addrs, 0, OBJF_SHARED);
> +    do_cleanups (old_chain);
>    }
>  
>    return (1);
> Index: symtab.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 symtab.h
> --- symtab.h	2000/03/14 19:58:02	1.3
> +++ symtab.h	2000/03/16 19:34:44
> @@ -842,7 +842,7 @@ struct section_offsets
>     can keep track of the section names until we read the file and
>     can map them to bfd sections. */
>   
> -#define MAX_SECTIONS 12
> +#define MAX_SECTIONS 30
>  struct section_addr_info 
>  {
>    /* Sections whose names are always known to gdb. */
> 
> 
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: gdb-patches@sourceware.cygnus.com, nickc@cygnus.com
Subject: Comments welcome (Was: Re: RFC: Patch to arm-tdep.c -- Register flavors)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AAEA0B.A3FF9C58@cygnus.com>
References: <38A9C3F4.20C62065@cygnus.com> <38A9E368.E309E33C@netwinder.org>
X-SW-Source: 2000-q1/msg00192.html
Content-length: 1488

On an aside from the thread, I would like to thanks Scott for his
comments.  We are in need of those as much as we are for patches (or
almost ;-).

With the volume of things going on, it is easy to make mistakes or
overlook a small detail.  Also, we get an indication of what are the
preferences (unfortunately the list does not have a percentage of users
high enough to be of statistical significance, but it is an indication
at least).

Thanks,
Fernando

Scott Bambrough wrote:
> 
> Fernando,
> 
> I have a couple of minor nits:
> 
> Could you submit a unified diff instead of the context diff.  It would be easier
> to read.  Personally I prefer diff -up.
> 
> I don't see the need for the code that is ifdef'ed out in _initialize_arm_tdep.
> You should resolve this before committing the patch.
> 
> Is the othernames command really necessary?  Perhaps we should take this
> opportunity to remove it.  I won't miss it.  It's just another command to
> document.
> 
> I think the default register names should be set by the port.  Most Linux users
> don't use the APCS/ATPCS register names.  I don't find them intuitive at all
> myself.
> 
> Scott
> 
> --
> Scott Bambrough - Software Engineer
> REBEL.COM    http://www.rebel.com
> NetWinder    http://www.netwinder.org

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From phdm@macqel.be Sat Apr 01 00:00:00 2000
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com)
Subject: HAVE_POLL is not enough
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002211141.MAA05937@mail.macqel.be>
X-SW-Source: 2000-q1/msg00277.html
Content-length: 1916

With the gdb cvs tree of 2000-02-19, on m68k-motorola-sys, configure
correctly detect  that we have `poll', but gdb incorrectly assumes that
`poll' can be used to wait for `stdin'.  On m68k-motorola-sysv, tty's
are not stream-based and not `poll'able.  Should the configure test
be enhanced ? I don't think so if we need to run a target program to check
that, because it would fail if we cross-compile gdb, but if it can be
determined by other ways, like the presence of some constants in some
header files then I would agree.  We could also always compile in the `poll'
version if HAVE_POLL, but switch to the the fall-back method at run time if
poll fails with POLLNVAL.

Meanwhile here is a small patch that at least tell the user what happened.

Mon Feb 21 12:39:44 2000  Philippe De Muyter  <phdm@macqel.be>

	* event-loop.c (handle_file_event): Issue an error message when
	poll fails.

--- ./gdb/event-loop.c	Mon Feb 21 12:35:54 2000
+++ ./gdb/event-loop.c	Sun Feb 20 19:04:50 2000
@@ -697,12 +697,12 @@ handle_file_event (int event_file_desc)
 	    {
 	      /* Work in progress. We may need to tell somebody what
 	         kind of error we had. */
-	      /*if (error_mask_returned & POLLHUP)
-	         printf_unfiltered ("Hangup detected on fd %d\n", file_ptr->fd);
-	         if (error_mask_returned & POLLERR)
-	         printf_unfiltered ("Error detected on fd %d\n", file_ptr->fd);
-	         if (error_mask_returned & POLLNVAL)
-	         printf_unfiltered ("Invalid fd %d\n", file_ptr->fd); */
+	      if (error_mask_returned & POLLHUP)
+	        printf_unfiltered ("Hangup detected on fd %d\n", file_ptr->fd);
+	      if (error_mask_returned & POLLERR)
+	        printf_unfiltered ("Error detected on fd %d\n", file_ptr->fd);
+	      if (error_mask_returned & POLLNVAL)
+	        printf_unfiltered ("Invalid or non-`poll'able fd %d\n", file_ptr->fd);
 	      file_ptr->error = 1;
 	    }
 	  else
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Minor patches for ARM Linux native port...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BAD90A.FE163BDA@netwinder.org>
X-SW-Source: 2000-q1/msg00402.html
Content-type: multipart/mixed; boundary="----------=_1583534363-29877-29"

This is a multi-part message in MIME format...

------------=_1583534363-29877-29
Content-length: 573

Hi guys,

I've checked the following patch to arm-linux-nat.c in.  This just cleans up
some build warnings and naming of functions.

2000-02-28  Scott Bambrough <scottb@netwinder.org>

        * config/arm/linux.mh (NATDEPFILES): Removed core-regset.o.
        Not used.  Required to get GDB to build on glibc 2.1.3.
        * config/arm/tm-linux.h (LOWEST_PC): Undefine LOWEST_PC 
        before redefining.  Gets rid of compiler warning.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
gdbarm.diff


------------=_1583534363-29877-29
Content-Type: text/x-diff; charset=us-ascii; name="gdbarm.diff"
Content-Disposition: inline; filename="gdbarm.diff"
Content-Transfer-Encoding: base64
Content-Length: 1497

SW5kZXg6IGNvbmZpZy9hcm0vbGludXgubWgNCj09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0NClJDUyBmaWxlOiAvY3ZzL3NyYy9zcmMvZ2RiL2NvbmZpZy9hcm0v
bGludXgubWgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjEuMS4xDQpkaWZm
IC11IC1wIC1yMS4xLjEuMSBsaW51eC5taA0KLS0tIGxpbnV4Lm1oCTE5OTkv
MTIvMjIgMjE6NDU6MTIJMS4xLjEuMQ0KKysrIGxpbnV4Lm1oCTIwMDAvMDIv
MjggMTk6NDk6MzUNCkBAIC01LDQgKzUsNCBAQCBYREVQRklMRVM9IHNlci10
Y3Aubw0KIA0KIE5BVF9GSUxFPSBubS1saW51eC5oDQogTkFUREVQRklMRVM9
IGluZnB0cmFjZS5vIHNvbGliLm8gaW5mdGFyZy5vIGZvcmstY2hpbGQubyBj
b3JlbG93Lm8gXA0KLQkgICAgIGNvcmUtYW91dC5vIGNvcmUtcmVnc2V0Lm8g
YXJtLWxpbnV4LW5hdC5vDQorCSAgICAgY29yZS1hb3V0Lm8gYXJtLWxpbnV4
LW5hdC5vDQpJbmRleDogY29uZmlnL2FybS90bS1saW51eC5oDQo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9zcmMvc3JjL2dkYi9j
b25maWcvYXJtL3RtLWxpbnV4Lmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAx
LjEuMS4xDQpkaWZmIC11IC1wIC1yMS4xLjEuMSB0bS1saW51eC5oDQotLS0g
dG0tbGludXguaAkxOTk5LzEyLzIyIDIxOjQ1OjEzCTEuMS4xLjENCisrKyB0
bS1saW51eC5oCTIwMDAvMDIvMjggMTk6NDk6MzUNCkBAIC02MSw2ICs2MSw3
IEBAIGV4dGVybiB2b2lkIGFybV9saW51eF9leHRyYWN0X3JldHVybl92YWwN
CiAJYXJtX2xpbnV4X2V4dHJhY3RfcmV0dXJuX3ZhbHVlICgoVFlQRSksIChS
RUdCVUYpLCAoVkFMQlVGKSkNCiANCiAvKiBUaGUgZmlyc3QgcGFnZSBpcyBu
b3Qgd3JpdGVhYmxlIGluIEFSTSBMaW51eC4gICovDQorI3VuZGVmIExPV0VT
VF9QQw0KICNkZWZpbmUgTE9XRVNUX1BDCTB4ODAwMA0KIA0KIC8qIERlZmlu
ZSBOT19TSU5HTEVfU1RFUCBpZiBwdHJhY2UoUFRfU1RFUCwuLi4pIGZhaWxz
IHRvIGZ1bmN0aW9uIGNvcnJlY3RseQ0K

------------=_1583534363-29877-29--
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] Configury changes for IA-64
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000321003058.ZM20160@ocotillo.lan>
X-SW-Source: 2000-q1/msg00835.html
Content-length: 1326

I seek approval for checking in the following changes:

	* configure.host, configure.tgt (ia64-*-linux*): New entry.

Index: configure.host
===================================================================
RCS file: /cvs/src/src/gdb/configure.host,v
retrieving revision 1.1.1.10
diff -u -p -r1.1.1.10 configure.host
--- configure.host	1999/12/22 21:45:03	1.1.1.10
+++ configure.host	2000/03/21 00:25:48
@@ -81,6 +81,9 @@ i[3456]86-*-unixware*)	gdb_host=i386v4 ;
 i[3456]86-*-sysv*)	gdb_host=i386v ;;
 i[3456]86-*-isc*)	gdb_host=i386v32 ;;
 i[3456]86-*-cygwin*)	gdb_host=cygwin ;;
+
+ia64-*-linux*)		gdb_host=linux ;;
+
 m680[01]0-sun-sunos3*)	gdb_host=sun2os3 ;;
 m680[01]0-sun-sunos4*)	gdb_host=sun2os4 ;;
 m68030-sony-*)		gdb_host=news1000 ;;
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.4
diff -u -p -r1.4 configure.tgt
--- configure.tgt	2000/02/24 03:31:45	1.4
+++ configure.tgt	2000/03/21 00:25:48
@@ -118,6 +118,8 @@ i[3456]86-*-osf1mk*)	gdb_target=i386mk ;
 i[3456]86-*-cygwin*)	gdb_target=cygwin  ;;
 i[3456]86-*-vxworks*)	gdb_target=vxworks ;;
 
+ia64-*-linux*)		gdb_target=linux ;;
+
 i960-*-bout*)		gdb_target=vxworks960 ;;
 i960-nindy-coff*)	gdb_target=nindy960 ;;
 i960-*-coff*)		gdb_target=mon960 ;;