From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Kevin Buettner Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] solib.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <1000316202058.ZM2781@ocotillo.lan> X-SW-Source: 2000-q1/msg00753.html 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 (§ion_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, > §ion_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 To: Scott Bambrough 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" 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 * 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 To: GDB Patches Mail List 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 * 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 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 ;;