* A patch for elf.c [not found] <Pine.LNX.3.96.981208082500.26204A-100000@beezer.med.miami.edu> @ 1998-12-08 9:57 ` H.J. Lu 1998-12-08 10:28 ` Christopher C Chimelis 1998-12-08 11:26 ` Ian Lance Taylor 0 siblings, 2 replies; 9+ messages in thread From: H.J. Lu @ 1998-12-08 9:57 UTC (permalink / raw) To: Christopher C Chimelis; +Cc: bfd, Ian Lance Taylor > > > On Mon, 7 Dec 1998, H.J. Lu wrote: > > > Could you please tell me on which platform you had this problem? > > Alpha running Debian Linux. Thanks for this information. BTW, have you mentioned this in your first bug report? I think this patch fixes the bug. Ian, this bug happens on ELF/Alpha when you strip more than one shared libraries at a time. It is not the first bfd_zalloc/bfd_alloc bug in bfd. It is quite annoying. -- H.J. Lu (hjl@gnu.org) ---- Tue Dec 8 07:51:09 1998 H.J. Lu (hjl@gnu.org) * elf.c (copy_private_bfd_data): Use bfd_zalloc instead of bfd_alloc. Index: elf.c =================================================================== RCS file: /home/work/cvs/gnu/binutils/bfd/elf.c,v retrieving revision 1.40 diff -u -p -r1.40 elf.c --- elf.c 1998/12/05 03:38:53 1.40 +++ elf.c 1998/12/08 17:48:01 @@ -3317,7 +3317,7 @@ copy_private_bfd_data (ibfd, obfd) /* Allocate a segment map big enough to contain all of the sections we have selected. */ m = ((struct elf_segment_map *) - bfd_alloc (obfd, + bfd_zalloc (obfd, (sizeof (struct elf_segment_map) + ((size_t) csecs - 1) * sizeof (asection *)))); if (m == NULL) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-08 9:57 ` A patch for elf.c H.J. Lu @ 1998-12-08 10:28 ` Christopher C Chimelis 1998-12-08 11:26 ` Ian Lance Taylor 1 sibling, 0 replies; 9+ messages in thread From: Christopher C Chimelis @ 1998-12-08 10:28 UTC (permalink / raw) To: H.J. Lu; +Cc: bfd, Ian Lance Taylor On Tue, 8 Dec 1998, H.J. Lu wrote: > Thanks for this information. BTW, have you mentioned this in your first > bug report? I think this patch fixes the bug. Unsure, but I think I mentioned it (sorry if I didn't). Thanks for your attention on this, btw. I'll test the patch tonight and get back to you tomorrow on it (my 533 MHz Alpha is offline right now so it'll have to build on the Multia). Thanks again... C ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-08 9:57 ` A patch for elf.c H.J. Lu 1998-12-08 10:28 ` Christopher C Chimelis @ 1998-12-08 11:26 ` Ian Lance Taylor 1998-12-08 11:34 ` Christopher C Chimelis 1998-12-09 7:42 ` H.J. Lu 1 sibling, 2 replies; 9+ messages in thread From: Ian Lance Taylor @ 1998-12-08 11:26 UTC (permalink / raw) To: hjl; +Cc: chris, bfd From: hjl@lucon.org (H.J. Lu) Date: Tue, 8 Dec 1998 09:57:19 -0800 (PST) > On Mon, 7 Dec 1998, H.J. Lu wrote: > > > Could you please tell me on which platform you had this problem? > > Alpha running Debian Linux. Thanks for this information. BTW, have you mentioned this in your first bug report? I think this patch fixes the bug. Ian, this bug happens on ELF/Alpha when you strip more than one shared libraries at a time. It is not the first bfd_zalloc/bfd_alloc bug in bfd. It is quite annoying. This bug was reported on bug-gnu-utils. I believe I have already fixed this problem with the appended patch. We've disagreed before on whether memory should be cleared when it is allocated, and I think we will continue to disagree. This was a bug introduced with a change to the function a few months ago. The fix is to avoid introducing bugs; clearing memory is just treating the symptom. Ian Index: elf.c =================================================================== RCS file: /cvs/cvsfiles/devo/bfd/elf.c,v retrieving revision 1.222 retrieving revision 1.223 diff -u -r1.222 -r1.223 --- elf.c 1998/11/18 04:26:38 1.222 +++ elf.c 1998/12/07 00:33:14 1.223 @@ -3444,6 +3444,8 @@ m->includes_filehdr = (p->p_offset == 0 && p->p_filesz >= iehdr->e_ehsize); + m->includes_phdrs = 0; + if (! phdr_included || p->p_type != PT_LOAD) { m->includes_phdrs = ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-08 11:26 ` Ian Lance Taylor @ 1998-12-08 11:34 ` Christopher C Chimelis 1998-12-09 7:42 ` H.J. Lu 1 sibling, 0 replies; 9+ messages in thread From: Christopher C Chimelis @ 1998-12-08 11:34 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: hjl, bfd On Tue, 8 Dec 1998, Ian Lance Taylor wrote: > This bug was reported on bug-gnu-utils. I believe I have already > fixed this problem with the appended patch. > > We've disagreed before on whether memory should be cleared when it is > allocated, and I think we will continue to disagree. This was a bug > introduced with a change to the function a few months ago. The fix is > to avoid introducing bugs; clearing memory is just treating the > symptom. I'll try both in turn and see. If Ian's patch is effective, then I'll stick to it. Thanks to both of you for this :-) C ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-08 11:26 ` Ian Lance Taylor 1998-12-08 11:34 ` Christopher C Chimelis @ 1998-12-09 7:42 ` H.J. Lu 1998-12-09 8:04 ` Roland McGrath 1998-12-09 9:35 ` Ian Lance Taylor 1 sibling, 2 replies; 9+ messages in thread From: H.J. Lu @ 1998-12-09 7:42 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: bfd > > We've disagreed before on whether memory should be cleared when it is > allocated, and I think we will continue to disagree. This was a bug We can agree on that :-). > introduced with a change to the function a few months ago. The fix is > to avoid introducing bugs; clearing memory is just treating the > symptom. > To me, clearing memory is the super set of setting one field to zero. I am a better safe than sorry person. I have no time to second guess if there is another field I should clear. -- H.J. Lu (hjl@gnu.org) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-09 7:42 ` H.J. Lu @ 1998-12-09 8:04 ` Roland McGrath 1998-12-09 9:35 ` Ian Lance Taylor 1 sibling, 0 replies; 9+ messages in thread From: Roland McGrath @ 1998-12-09 8:04 UTC (permalink / raw) To: H.J. Lu; +Cc: Ian Lance Taylor, bfd > To me, clearing memory is the super set of setting one field to > zero. I am a better safe than sorry person. I have no time > to second guess if there is another field I should clear. It is indeed the superset of setting one field to zero. The question is whether, generically speaking, setting a field to zero is the appropriate way to initialize it. It is not appropriate in all cases, so clearing memory is not necessarily a superset of appropriately initializing each field. If I may presume to explain another's position, I think Ian (like me), also considers himself a "better safe than sorry" person. For us, that means it is better to be safe by individually addressing each case with a human eye and being sure that case is handled properly, than to be sorry by presuming that some nonspecific blanket solution like zeroing everything will be the appropriate way to initialize each and every field. (What I prefer to do myself is use a debugging version of malloc that fills newly-allocated space with a distinctive nonzero bit pattern, e.g. 0xa5a5a5a5, that makes it unlikely that the program could happen to work if a field is left uninitialized.) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-09 7:42 ` H.J. Lu 1998-12-09 8:04 ` Roland McGrath @ 1998-12-09 9:35 ` Ian Lance Taylor 1998-12-09 10:03 ` Jeffrey A Law 1998-12-09 16:27 ` Stan Shebs 1 sibling, 2 replies; 9+ messages in thread From: Ian Lance Taylor @ 1998-12-09 9:35 UTC (permalink / raw) To: hjl; +Cc: bfd From: hjl@lucon.org (H.J. Lu) Date: Wed, 9 Dec 1998 07:42:46 -0800 (PST) > introduced with a change to the function a few months ago. The fix is > to avoid introducing bugs; clearing memory is just treating the > symptom. To me, clearing memory is the super set of setting one field to zero. I am a better safe than sorry person. I have no time to second guess if there is another field I should clear. I know you don't mean this, but to me ``I have no time to second guess'' sounds like ``I have no time to figure out how the code works, or what the right patch is.'' In a long running project like GNU, anybody who wants to make changes has to take the time to understand them. We're not quickly hacking stuff together for the big demo next Wednesday; we're writing code that should, ideally, survive for twenty years. I also agree with Roland's point. Ian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-09 9:35 ` Ian Lance Taylor @ 1998-12-09 10:03 ` Jeffrey A Law 1998-12-09 16:27 ` Stan Shebs 1 sibling, 0 replies; 9+ messages in thread From: Jeffrey A Law @ 1998-12-09 10:03 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: hjl, bfd In message < 199812091735.MAA29788@subrogation.cygnus.com >you write: > > introduced with a change to the function a few months ago. The fix is > > to avoid introducing bugs; clearing memory is just treating the > > symptom. > > To me, clearing memory is the super set of setting one field to > zero. I am a better safe than sorry person. I have no time > to second guess if there is another field I should clear. > > I know you don't mean this, but to me ``I have no time to second > guess'' sounds like ``I have no time to figure out how the code works, > or what the right patch is.'' In a long running project like GNU, > anybody who wants to make changes has to take the time to understand > them. We're not quickly hacking stuff together for the big demo next > Wednesday; we're writing code that should, ideally, survive for twenty > years. > > I also agree with Roland's point. IMHO, clearing a block of memory to fix a problem without understanding precisely why clearing the block fixes the problem is just papering over a bug. Once one understands precisely why clearing one or more memory locations is fixing a bug, once can decide if clearing one or more fields or a whole structure/array is the best solution. I believe gdb operates under a similar guidelines. jeff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A patch for elf.c 1998-12-09 9:35 ` Ian Lance Taylor 1998-12-09 10:03 ` Jeffrey A Law @ 1998-12-09 16:27 ` Stan Shebs 1 sibling, 0 replies; 9+ messages in thread From: Stan Shebs @ 1998-12-09 16:27 UTC (permalink / raw) To: bfd law@hurl.cygnus.com (Jeffrey A Law) writes: > Once one understands precisely why clearing one or more memory locations is > fixing a bug, once can decide if clearing one or more fields or a whole > structure/array is the best solution. > > I believe gdb operates under a similar guidelines. Yes. There is actually a real reason to not just automatically zero everything - in some cases, the blocks are very large, and it's known that they will be overwritten soon, such as when BFD reads in a whole section. So zeroing all allocated blocks chews execution time uselessly. This is just a GNU standard. In my other program (Xconq), everything is zeroed upon allocation, and the rest of the code is designed to exploit that. Stan ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1998-12-09 16:27 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Pine.LNX.3.96.981208082500.26204A-100000@beezer.med.miami.edu> 1998-12-08 9:57 ` A patch for elf.c H.J. Lu 1998-12-08 10:28 ` Christopher C Chimelis 1998-12-08 11:26 ` Ian Lance Taylor 1998-12-08 11:34 ` Christopher C Chimelis 1998-12-09 7:42 ` H.J. Lu 1998-12-09 8:04 ` Roland McGrath 1998-12-09 9:35 ` Ian Lance Taylor 1998-12-09 10:03 ` Jeffrey A Law 1998-12-09 16:27 ` Stan Shebs
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).