Subject: Re: README: changes to libbfd for m68k people
To: None <current-users@NetBSD.ORG, port-m68k@NetBSD.ORG, tech-toolchain@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-toolchain
Date: 07/12/1998 17:23:07
> [...] because of what I consider to be bugs in the binutils[*].

> [*] The bug is that the binutils directly access libbfd's selected
> targets vector, rather than calling libbfd functions (which don't
> exist, grr) to access the vector.  This means that the size of
> selected vector symbol changes, in this case growing by 4 bytes
> because 1 vector was added, and issues a warning and does only
> the "expected" size.

In my opinion this is a bug in  How many more "bugs" are we
going to have to run into because of it before we fix it?

(Yes, it's fixable.  All you have to do is keep the size along with the
rest of the symbol info in the executable, then at time, if the
size has changed, resolve to the data segment of the library instead of
to the copy in data/bss space.  This means losing shared-library
sharing on the affected page(s), but really, it seems very penny-wise
and pound-foolish to consider that sharing precious enough to be worth
breaking library semantics like this for.  Besides, it can always be
cured by relinking, which is the cure for the present brokenness, and
surely it's better to be slightly inefficient until relinked than to be
coredump-level broken until relinked.)

As for this particular case (and the other one, too - IIRC it was
sys_errlist[]), why not declare the array const, which should push it
into the text segment, in which case the size clash issue completely

					der Mouse

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B