home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cis.ohio-state.edu!cc.helsinki.FI!kankkune
- From: kankkune@cc.helsinki.FI (Risto Kankkunen)
- Newsgroups: gnu.utils.bug
- Subject: BUG in ld from binutils 2.0
- Date: 25 Jan 1993 20:20:05 -0500
- Organization: University of Helsinki, Department of Computer Science
- Lines: 72
- Sender: daemon@cis.ohio-state.edu
- Approved: bug-gnu-utils@prep.ai.mit.edu
- Distribution: gnu
- Message-ID: <1993Jan23.234812.28977@klaava.Helsinki.FI>
-
- OK, I'm very pissed off now having twice failed to send a long and
- detailed bug report of ld. That damned PNews doesn't like to be
- suspended. Here's a terse version of what I intended to say:
-
- configure --host=sun4 --target=i386-linux --prefix=$HOME
-
- 1. the above configuration sets the default emulation to be the null
- string, which ld doesn't like.
-
- 2. Isn't there really a command line option to set the output format?
- There definitely should be. If I use the vanilla emulation, all I get is
- files in the format sunos-big or something like that. Am I really
- expected to make a new emulation only to override that to be the linux
- format, when the vanilla emulation suits me fine otherwise? Changing the
- order of format names in the array doesn't seem to be a good solution,
- either.
-
- 3. ld doesn't like parentheses in the format name in command line, and
- the linux format name happens to have these. The command "ld -b
- 'a.out-i386(linux)' foo" produces:
-
- ld: Can't open linux
- ()
-
- without terminating newline.
-
- 4. Linux has a page and segment size of 4K while the header size is 1K.
- You could achieve this somewhat unusual format with bintutils 1.9 by
- lying the segment size to be 1K. The configuration files in 2.0 still
- have this trick, although it now produces incorrect code (data segment
- gets overwritten by symbols etc.).
-
- There isn't a clean fix for this. It appears that ld uses heuristics
- that override all the settings in the bfd include files or emulation
- definitions concerning the executable header size. The following
- stop-gap change helps to find the problem area.
-
- What puzzles me is why the generic ld code uses such heuristics.
- Shouldn't it leave it to bfd to determine the sizes of the various parts
- in the executable? There are already the routines 'set_sizes' and
- 'callback' in bfd. Shouldn't these or similar functions be called
- instead of any heuristics?
-
- PLEASE, mail me a copy of your comments even if you intended only to
- post to the group. I'm out of my news connection for a month starting on
- Monday, and while I may not be able to read my mail during that period
- it at least gets stored for me to read later.
-
- *** ./bfd/aoutx.h.orig Thu Dec 17 19:47:25 1992
- --- ./bfd/aoutx.h Thu Dec 17 19:46:33 1992
- ***************
- *** 708,714 ****
- ztih = abdp && abdp->text_includes_header;
- obj_textsec(abfd)->filepos = (ztih
- ? adata(abfd).exec_bytes_size
- ! : adata(abfd).page_size);
- if (! obj_textsec(abfd)->user_set_vma)
- /* ?? Do we really need to check for relocs here? */
- obj_textsec(abfd)->vma = ((abfd->flags & HAS_RELOC)
- --- 708,715 ----
- ztih = abdp && abdp->text_includes_header;
- obj_textsec(abfd)->filepos = (ztih
- ? adata(abfd).exec_bytes_size
- ! /* : adata(abfd).page_size);
- ! */ : 1024);
- if (! obj_textsec(abfd)->user_set_vma)
- /* ?? Do we really need to check for relocs here? */
- obj_textsec(abfd)->vma = ((abfd->flags & HAS_RELOC)
-
- --
- dos, windows, nt... are you a victim of the MS disease?
-
-