* elf.sc and shared library for binutils @ 1995-02-25 14:08 H.J. Lu 1995-02-25 14:10 ` Eric Youngdale 1995-02-25 14:17 ` Ian Lance Taylor 0 siblings, 2 replies; 5+ messages in thread From: H.J. Lu @ 1995-02-25 14:08 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gas2, Eric Youngdale Here are some comments from elf.sc: /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. It would be more correct to do this: ${RELOCATING+. = ${DATA_ADDR-ALIGN(${MAXPAGESIZE}) + ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE})) & (${MAXPAGESIZE} - 1)};} I think the correct one should be ${RELOCATING+. = ALIGN(${MAXPAGESIZE}) + ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE})) & (${MAXPAGESIZE} - 1)};} It should be independent of DATA_ADDR. I have been adding the ELF shared library support for binutils under Linux for a while. Any chance to support it in the official source? H.J. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elf.sc and shared library for binutils 1995-02-25 14:08 elf.sc and shared library for binutils H.J. Lu @ 1995-02-25 14:10 ` Eric Youngdale 1995-02-27 6:54 ` Mike Meissner 1995-02-25 14:17 ` Ian Lance Taylor 1 sibling, 1 reply; 5+ messages in thread From: Eric Youngdale @ 1995-02-25 14:10 UTC (permalink / raw) To: H.J. Lu, Ian Lance Taylor; +Cc: gas2 On Feb 25, 5:06pm, H.J. Lu wrote: > Subject: elf.sc and shared library for binutils > Here are some comments from elf.sc: > > /* Adjust the address for the data segment. We want to adjust up to > the same address within the page on the next page up. It would > be more correct to do this: Maybe I am missing something, but why is this so important. All we end up doing is wasting one page of VM (not physical memory, just virtual memory). Is there something else here? -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elf.sc and shared library for binutils 1995-02-25 14:10 ` Eric Youngdale @ 1995-02-27 6:54 ` Mike Meissner 1995-02-27 21:39 ` Ian Lance Taylor 0 siblings, 1 reply; 5+ messages in thread From: Mike Meissner @ 1995-02-27 6:54 UTC (permalink / raw) To: eric; +Cc: hjl, ian, gas2 | On Feb 25, 5:06pm, H.J. Lu wrote: | > Subject: elf.sc and shared library for binutils | > Here are some comments from elf.sc: | > | > /* Adjust the address for the data segment. We want to adjust up | to | > the same address within the page on the next page up. It | would | > be more correct to do this: | | Maybe I am missing something, but why is this so important. | All we | end up doing is wasting one page of VM (not physical memory, just | virtual memory). | Is there something else here? If you don't do this, each program will be one physical page larger, since the pages in the data area would start on a new page, leaving a hole in the program file as it exists on disk between the text and data. This is why V.4 specifies this behavior. -- Michael Meissner, Cygnus Support (East Coast) Suite 105, 48 Grove Street, Somerville, MA 02144, USA meissner@cygnus.com, 617-629-3016 (office), 617-629-3010 (fax) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elf.sc and shared library for binutils 1995-02-27 6:54 ` Mike Meissner @ 1995-02-27 21:39 ` Ian Lance Taylor 0 siblings, 0 replies; 5+ messages in thread From: Ian Lance Taylor @ 1995-02-27 21:39 UTC (permalink / raw) To: meissner; +Cc: eric, hjl, gas2 From: Mike Meissner <meissner@cygnus.com> Date: Mon, 27 Feb 1995 09:54:13 -0500 If you don't do this, each program will be one physical page larger, since the pages in the data area would start on a new page, leaving a hole in the program file as it exists on disk between the text and data. The linker already does this. The issue at hand is more subtle. It is how to handle a program whose text segment ends precisely on a page boundary. Ideally the data segment should start on the next page, immediately following the text segment. Currently the linker will skip a page, wasting a page of virtual memory address space. Fixing this is complex; see the comment in ld/scripttempl/elf.sc. Ian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: elf.sc and shared library for binutils 1995-02-25 14:08 elf.sc and shared library for binutils H.J. Lu 1995-02-25 14:10 ` Eric Youngdale @ 1995-02-25 14:17 ` Ian Lance Taylor 1 sibling, 0 replies; 5+ messages in thread From: Ian Lance Taylor @ 1995-02-25 14:17 UTC (permalink / raw) To: hjl; +Cc: gas2, eric From: hjl@nynexst.com (H.J. Lu) Date: Sat, 25 Feb 95 17:06:41 EST Here are some comments from elf.sc: /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. It would be more correct to do this: ${RELOCATING+. = ${DATA_ADDR-ALIGN(${MAXPAGESIZE}) + ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE})) & (${MAXPAGESIZE} - 1)};} I think the correct one should be ${RELOCATING+. = ALIGN(${MAXPAGESIZE}) + ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE})) & (${MAXPAGESIZE} - 1)};} It should be independent of DATA_ADDR. I believe that it should depend upon DATA_ADDR if it is set. Note that most targets do not set DATA_ADDR. However, Irix 5 does set DATA_ADDR. On Irix 5, unlike most ELF targets, the .data section always starts at 0x10000000. I think the GNU linker may as well be compatible. In any case, since DATA_ADDR is not normally set, why bother to make this change? I have been adding the ELF shared library support for binutils under Linux for a while. Any chance to support it in the official source? Yes, I would think so. I was not aware that there was any shared library support that was not in the FSF sources. What sort of stuff is it? Ian ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1995-02-27 21:39 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1995-02-25 14:08 elf.sc and shared library for binutils H.J. Lu 1995-02-25 14:10 ` Eric Youngdale 1995-02-27 6:54 ` Mike Meissner 1995-02-27 21:39 ` Ian Lance Taylor 1995-02-25 14:17 ` Ian Lance Taylor
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).