From: Minh Tran-Le <TRANLE@intellicorp.com>
To: gas2@cygnus.com
Subject: problem with ld (i386-coff) leaving holes in the executable ...
Date: Sun, 07 Aug 1994 10:59:00 -0000 [thread overview]
Message-ID: <199408071759.KAA13172@cygnus.com> (raw)
The latest GNU ld does not produce an executable with a consistent
image header. If you take each section and add up its scnptr+scnsize
it does not always match the scnptr of the next section with content.
And this seems to confuse Emacs unexec which end up dumping the wrong
content for the .lib section.
Does anybody knows why the new ld leave holes in the executable ?
Here is a testcase and output of dump using the old ld and the new ld.
=====================
1 mtranle@paris> cat foo.c
#include <stdio.h>
main()
{ printf("hi\n"); }
/* foo.good has been linked using GNU ld of may-31 */
2 mtranle@paris> dump -h foo.good
***SECTION HEADER***
Name Paddr Vaddr Scnptr Relptr Lnnoptr
Flags Size Nreloc Nlnno
foo.good:
.text 0x00000120 0x00000120 0x00000120 0x00000000 0x0000f80c
0x00000020 0x00009628 0 2
/* 0x120 + 0x9628 => 0x9748 */
.data 0x00400748 0x00400748 0x00009748 0x00000000 0x00000000
0x00000040 0x0000609c 0 0
/* 0x9748 + 0x609c => 0xf7e4 */
.bss 0x004067e4 0x004067e4 0x00000000 0x00000000 0x00000000
0x00000080 0x000027a4 0 0
.stab 0x00408f88 0x00408f88 0x00000000 0x00000000 0x00000000
0x00000200 0x00000000 0 0
.stabstr 0x00408f88 0x00408f88 0x00000000 0x00000000 0x00000000
0x00000200 0x00000000 0 0
/* .comment section scnptr 0xf7e4 */
.comment 0x00000000 0x00000000 0x0000f7e4 0x00000000 0x00000000
0x00000200 0x00000028 0 0
/* foo.bad has been linked using the latest GNU ld and
scnptr + scnsize does not match the scnptr of the next section */
3 mtranle@paris> dump -h foo.bad
***SECTION HEADER***
Name Paddr Vaddr Scnptr Relptr Lnnoptr
Flags Size Nreloc Nlnno
foo.bad:
.text 0x000000d0 0x000000d0 0x000000d0 0x00000000 0x0000ff60
0x00000020 0x00009628 0 2
/* 0xd0 + 0x9628 => 0x96f8 */
.data 0x004006f8 0x004006f8 0x000096f8 0x00000000 0x00000000
0x00000040 0x0000609c 0 0
/* 0x96f8 + 0x609c => 0xf794 */
.bss 0x00406794 0x00406794 0x00000000 0x00000000 0x00000000
0x00000080 0x000027a4 0 0
/* 0xf794 does not match .comment
scnptr. There is a gap between
end of .data and beginning of
.comment */
.comment 0x00408f38 0x00408f38 0x0000ff38 0x00000000 0x00000000
0x00000200 0x00000028 0 0
4 mtranle@paris> exit
=================
Thanks,
Minh Tran-Le.
-------
next reply other threads:[~1994-08-07 10:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1994-08-07 10:59 Minh Tran-Le [this message]
1994-08-08 7:59 ` Ian Lance Taylor
1994-08-08 20:11 ` problem with ld (i386-coff) leaving holes in the Minh Tran-Le
1994-08-09 6:58 ` Ian Lance Taylor
1994-08-09 14:11 ` Minh Tran-Le
1994-08-10 10:03 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199408071759.KAA13172@cygnus.com \
--to=tranle@intellicorp.com \
--cc=gas2@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).