* problem with ld (i386-coff) leaving holes in the executable ...
@ 1994-08-07 10:59 Minh Tran-Le
1994-08-08 7:59 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Minh Tran-Le @ 1994-08-07 10:59 UTC (permalink / raw)
To: gas2
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.
-------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with ld (i386-coff) leaving holes in the executable ...
1994-08-07 10:59 problem with ld (i386-coff) leaving holes in the executable Minh Tran-Le
@ 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
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 1994-08-08 7:59 UTC (permalink / raw)
To: tranle; +Cc: gas2
Date: Sun, 7 Aug 94 10:57:26 PDT
From: Minh Tran-Le <TRANLE@intellicorp.com>
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 ?
This was done because on a demand paged system, the file position of a
section must match the page position within the executable file,
modulo the page size. Forcing this alignment permits sections to be
removed from the middle of the file, which is desirable when the
debugging information is stored in a separate COFF section, as it is
for stabs debugging information.
However, this alignment is only required for sections which are
allocated in memory. Could you please try this patch, and see if it
fixes the problem?
Ian
*** coffcode.h.~15~ Wed Aug 3 10:22:07 1994
--- coffcode.h Mon Aug 8 10:48:52 1994
*************** coff_compute_section_file_positions (abf
*** 1378,1384 ****
#ifdef COFF_PAGE_SIZE
/* In demand paged files the low order bits of the file offset
must match the low order bits of the virtual address. */
! if ((abfd->flags & D_PAGED) != 0)
sofar += (current->vma - sofar) % COFF_PAGE_SIZE;
#endif
--- 1378,1385 ----
#ifdef COFF_PAGE_SIZE
/* In demand paged files the low order bits of the file offset
must match the low order bits of the virtual address. */
! if ((abfd->flags & D_PAGED) != 0
! && (current->flags & SEC_ALLOC) != 0)
sofar += (current->vma - sofar) % COFF_PAGE_SIZE;
#endif
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with ld (i386-coff) leaving holes in the
1994-08-08 7:59 ` Ian Lance Taylor
@ 1994-08-08 20:11 ` Minh Tran-Le
1994-08-09 6:58 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Minh Tran-Le @ 1994-08-08 20:11 UTC (permalink / raw)
To: ian; +Cc: gas2
Ian Lance Taylor <ian@cygnus.com> wrote:
|
|This was done because on a demand paged system, the file position of a
|section must match the page position within the executable file,
|modulo the page size. Forcing this alignment permits sections to be
|removed from the middle of the file, which is desirable when the
|debugging information is stored in a separate COFF section, as it is
|for stabs debugging information.
|
|However, this alignment is only required for sections which are
|allocated in memory. Could you please try this patch, and see if it
|fixes the problem?
|
|Ian
|
|*** coffcode.h.~15~ Wed Aug 3 10:22:07 1994
|--- coffcode.h Mon Aug 8 10:48:52 1994
|*************** coff_compute_section_file_positions (abf
|*** 1378,1384 ****
| #ifdef COFF_PAGE_SIZE
| /* In demand paged files the low order bits of the file offset
| must match the low order bits of the virtual address. */
|! if ((abfd->flags & D_PAGED) != 0)
| sofar += (current->vma - sofar) % COFF_PAGE_SIZE;
| #endif
|
|--- 1378,1385 ----
| #ifdef COFF_PAGE_SIZE
| /* In demand paged files the low order bits of the file offset
| must match the low order bits of the virtual address. */
|! if ((abfd->flags & D_PAGED) != 0
|! && (current->flags & SEC_ALLOC) != 0)
| sofar += (current->vma - sofar) % COFF_PAGE_SIZE;
| #endif
|
This patch seems to work fine for me on small executable but on emacs
it still fail and still try to page align the `.comment' section.
I made ld printout the section name and flags in the case it wants to
page align it.
section .text: flags 0x237
section .data: flags 0x247
section .comment: flags 0x10203
section .lib: flags 0x203
== output of: dump -h temacs ==
***SECTION HEADER***
Name Paddr Vaddr Scnptr Relptr Lnnoptr
Flags Size Nreloc Nlnno
temacs:
.text 0x00000148 0x00000148 0x00000148 0x00000000 0x0014e2a8
0x00000020 0x000e731c 0 2
.data 0x00400464 0x00400464 0x000e7464 0x00000000 0x00000000
0x00000040 0x00047bc4 0 0
.bss 0x00448028 0x00448028 0x00000000 0x00000000 0x00000000
0x00000080 0x00025ff8 0 0
/* page aligned here */
.comment 0x0046e020 0x0046e020 0x00130020 0x00000000 0x00000000
0x00000200 0x0001e270 0 0
.fkd800 0xd8000000 0xd8000000 0x00000000 0x00000000 0x00000000
0x00000022 0x0003a858 0 0
.lib 0x00000001 0x00000000 0x0014e290 0x00000000 0x00000000
0x00000800 0x00000018 0 0
.fkdc00 0xdc000000 0xdc000000 0x00000000 0x00000000 0x00000000
0x00000042 0x0000f28c 0 0
I have tried to comment out the code that was doing the page align
and it cure the problem with emacs unexec without any adverse effect.
Does all standard COFF linker do this page align thing ? Does emacs unexec
work fine with them ?
Thanks,
Minh Tran-Le.
-------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with ld (i386-coff) leaving holes in the
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
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 1994-08-09 6:58 UTC (permalink / raw)
To: tranle; +Cc: gas2
Date: Mon, 8 Aug 94 19:47:36 PDT
From: Minh Tran-Le <TRANLE@intellicorp.com>
I made ld printout the section name and flags in the case it wants to
page align it.
section .text: flags 0x237
section .data: flags 0x247
section .comment: flags 0x10203
section .lib: flags 0x203
Can you find out what SEC_LOAD and SEC_ALLOC are set for all the
sections? I don't see why they should be set for .comment or .lib.
I have tried to comment out the code that was doing the page align
and it cure the problem with emacs unexec without any adverse effect.
Unfortunately, removing the code will break other cases.
Does all standard COFF linker do this page align thing ? Does emacs unexec
work fine with them ?
Standard COFF linkers certainly do the page alignment in some form.
In previous versions of the GNU linker, the page alignment was forced
by the linker script. I added the code in coffcode.h to make the page
alignment work when strip was used and it removed some sections.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with ld (i386-coff) leaving holes in the
1994-08-09 6:58 ` Ian Lance Taylor
@ 1994-08-09 14:11 ` Minh Tran-Le
1994-08-10 10:03 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Minh Tran-Le @ 1994-08-09 14:11 UTC (permalink / raw)
To: ian; +Cc: gas2
|Ian Lance Taylor <ian@cygnus.com> wrote:
|
| Date: Mon, 8 Aug 94 19:47:36 PDT
| From: Minh Tran-Le <TRANLE@intellicorp.com>
|
| I made ld printout the section name and flags in the case it wants to
| page align it.
|
| section .text: flags 0x237
| section .data: flags 0x247
| section .comment: flags 0x10203
| section .lib: flags 0x203
|
|Can you find out what SEC_LOAD and SEC_ALLOC are set for all the
|sections? I don't see why they should be set for .comment or .lib.
Well looking at the function styp_to_sec_flags in coffcode.h it seems
that it is setting the section flags to SEC_LOAD|SEC_ALLOC (line 462)
for all styp_flags that it does not know about.
For i386-aix, the .comment sections have either an styp of either
0x0 or 0x200 and the .lib sections have an styp of 0x800. So the
function stype_to_sec_load will return for some of the .comment
sections and all the .lib the value 0x3 which is SEC_LOAD|SEC_ALLOC.
Maybe the function styp_to_sec_flags should not set the default
section flags to SEC_LOAD|SEC_ALLOC.
Minh Tran-Le.
-------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problem with ld (i386-coff) leaving holes in the
1994-08-09 14:11 ` Minh Tran-Le
@ 1994-08-10 10:03 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 1994-08-10 10:03 UTC (permalink / raw)
To: tranle; +Cc: gas2
Date: Tue, 9 Aug 94 13:43:16 PDT
From: Minh Tran-Le <TRANLE@intellicorp.com>
Maybe the function styp_to_sec_flags should not set the default
section flags to SEC_LOAD|SEC_ALLOC.
I'm scared to make that change. I'm sure it would break on some
system in a way that would be difficult to fix. How about the
following (untested) patch instead? After installing this, do ``make
headers'' in the bfd object directory to rebuild libcoff.h.
Ian
*** coffcode.h.~16~ Mon Aug 8 10:48:52 1994
--- coffcode.h Wed Aug 10 12:07:20 1994
*************** sec_to_styp_flags (sec_name, sec_flags)
*** 405,413 ****
* in sec_to_styp_flags().
*/
static flagword
! styp_to_sec_flags (abfd, hdr)
! bfd * abfd;
PTR hdr;
{
struct internal_scnhdr *internal_s = (struct internal_scnhdr *) hdr;
long styp_flags = internal_s->s_flags;
--- 405,414 ----
* in sec_to_styp_flags().
*/
static flagword
! styp_to_sec_flags (abfd, hdr, name)
! bfd *abfd;
PTR hdr;
+ const char *name;
{
struct internal_scnhdr *internal_s = (struct internal_scnhdr *) hdr;
long styp_flags = internal_s->s_flags;
*************** styp_to_sec_flags (abfd, hdr)
*** 457,462 ****
--- 458,511 ----
sec_flags |= SEC_DEBUGGING;
#endif
}
+ else if (strcmp (name, _TEXT) == 0)
+ {
+ if (sec_flags & SEC_NEVER_LOAD)
+ sec_flags |= SEC_CODE | SEC_COFF_SHARED_LIBRARY;
+ else
+ sec_flags |= SEC_CODE | SEC_LOAD | SEC_ALLOC;
+ }
+ else if (strcmp (name, _DATA) == 0
+ #ifdef TWO_DATA_SECS
+ || strcmp (name, ".data2") == 0
+ #endif
+ )
+ {
+ if (sec_flags & SEC_NEVER_LOAD)
+ sec_flags |= SEC_DATA | SEC_COFF_SHARED_LIBRARY;
+ else
+ sec_flags |= SEC_DATA | SEC_LOAD | SEC_ALLOC;
+ }
+ else if (strcmp (name, _BSS) == 0)
+ {
+ #ifdef BSS_NOLOAD_IS_SHARED_LIBRARY
+ if (sec_flags & SEC_NEVER_LOAD)
+ sec_flags |= SEC_ALLOC | SEC_COFF_SHARED_LIBRARY;
+ else
+ #endif
+ sec_flags |= SEC_ALLOC;
+ }
+ else if (strcmp (name, ".debug") == 0
+ #ifdef _COMMENT
+ || strcmp (name, _COMMENT) == 0
+ #endif
+ || strcmp (name, ".stab") == 0
+ || strcmp (name, ".stabstr") == 0)
+ {
+ #ifdef COFF_PAGE_SIZE
+ sec_flags |= SEC_DEBUGGING;
+ #endif
+ }
+ #ifdef _LIB
+ else if (strcmp (name, _LIB) == 0)
+ ;
+ #endif
+ #ifdef _LIT
+ else if (strcmp (name, _LIT) == 0)
+ {
+ sec_flags = SEC_LOAD | SEC_ALLOC | SEC_READONLY;
+ }
+ #endif
else
{
sec_flags |= SEC_ALLOC | SEC_LOAD;
*************** dependent COFF routines:
*** 585,591 ****
. PTR internal_aouthdr));
. flagword (*_bfd_styp_to_sec_flags_hook) PARAMS ((
. bfd *abfd,
! . PTR internal_scnhdr));
. asection *(*_bfd_make_section_hook) PARAMS ((
. bfd *abfd,
. char *name));
--- 634,641 ----
. PTR internal_aouthdr));
. flagword (*_bfd_styp_to_sec_flags_hook) PARAMS ((
. bfd *abfd,
! . PTR internal_scnhdr,
! . const char *name));
. asection *(*_bfd_make_section_hook) PARAMS ((
. bfd *abfd,
. char *name));
*************** dependent COFF routines:
*** 671,678 ****
.#define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\
. ((coff_backend_info (abfd)->_bfd_coff_mkobject_hook) (abfd, filehdr, aouthdr))
.
! .#define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr)\
! . ((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook) (abfd, scnhdr))
.
.#define bfd_coff_make_section_hook(abfd, name)\
. ((coff_backend_info (abfd)->_bfd_make_section_hook) (abfd, name))
--- 721,728 ----
.#define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\
. ((coff_backend_info (abfd)->_bfd_coff_mkobject_hook) (abfd, filehdr, aouthdr))
.
! .#define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr, name)\
! . ((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook) (abfd, scnhdr, name))
.
.#define bfd_coff_make_section_hook(abfd, name)\
. ((coff_backend_info (abfd)->_bfd_make_section_hook) (abfd, name))
Index: coffgen.c
===================================================================
RCS file: /rel/cvsfiles/devo/bfd/coffgen.c,v
retrieving revision 1.34
diff -p -r1.34 coffgen.c
*** coffgen.c 1994/06/21 16:46:51 1.34
--- coffgen.c 1994/08/10 17:03:06
*************** make_a_section_from_file (abfd, hdr, tar
*** 99,105 ****
return_section->lineno_count = hdr->s_nlnno;
return_section->userdata = NULL;
return_section->next = (asection *) NULL;
! return_section->flags = bfd_coff_styp_to_sec_flags_hook (abfd, hdr);
return_section->target_index = target_index;
--- 99,105 ----
return_section->lineno_count = hdr->s_nlnno;
return_section->userdata = NULL;
return_section->next = (asection *) NULL;
! return_section->flags = bfd_coff_styp_to_sec_flags_hook (abfd, hdr, name);
return_section->target_index = target_index;
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1994-08-10 10:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1994-08-07 10:59 problem with ld (i386-coff) leaving holes in the executable Minh Tran-Le
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
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).