Re: [PATCH RFA] solib.c

Jim Blandy
2000-04-01T00:00:00Z

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