From: jont AT harlequin DOT co DOT uk (Jon Thackray)
Subject: Re: Section attributes from ld
16 Jul 1997 08:33:19 -0700
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199707161317.OAA27491.cygnus.gnu-win32@zaphod.long.harlequin.co.uk>
References: <199707151105 DOT MAA14711 AT zaphod DOT long DOT harlequin DOT co DOT uk>
	<199707152216 DOT SAA07402 AT tweedledumb DOT cygnus DOT com>
	<199707161156 DOT MAA27248 AT zaphod DOT long DOT harlequin DOT co DOT uk>
Original-To: ian AT cygnus DOT com, gnu-win32 AT cygnus DOT com
In-Reply-To: <199707161156.MAA27248@zaphod.long.harlequin.co.uk>
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Jon Thackray writes:
 > ian AT cygnus DOT com writes:
 >  > >How does ld determine which attributes sections are to have? By
 >  > >attributes, I mean things like:-
 >  > 
 >  > >Contains code, contains initialised data, should be laoded with
 >  > >execute permission, should be loaded with read permission, should be
 >  > >loaded with write permission etc.
 >  > 
 >  > The attributes are based on the attributes of the input sections which
 >  > are mapped into the output sections.  Take a look at
 >  > gas/config/obj-coff.c to see how to use the .section directive in an
 >  > assembler file.
 > 
 > As far as I can see, this allows me no control over the flags I'm
 > talking about. The ones I mean are documented in MSDN as:-
 > 
 > IMAGE_SCN_MEM_DISCARDABLE	0x02000000
 > IMAGE_SCN_MEM_NOT_CACHED	0x04000000
 > IMAGE_SCN_MEM_NOT_PAGED		0x08000000
 > IMAGE_SCN_MEM_SHARED		0x10000000
 > IMAGE_SCN_MEM_EXECUTE		0x20000000
 > IMAGE_SCN_MEM_READ		0x40000000
 > IMAGE_SCN_MEM_WRITE		0x80000000
 > 
 > It would appear that as automatcially puts MEM_READ and MEM_EXECUTE on
 > the .text section, MEM_READ and MEM_WRITE on the .data section and the
 > same on the .bss section. For sections it doesn't know about (eg I
 > have one called .dyfix), it outs none of these. However, my compiler,
 > when generating these sections, does add attributes such as MEM_READ
 > and MEM_WRITE, but then ld appears to throw them away (at least binary
 > editing the resulting executable or looking at it with any of the
 > tools available shows them to have gone away).

As an experiment, I made an object file without the MEM_EXECUTE flag
for the .text section, and then linked it (with nothing else at all).
ld put the MEM_EXECUTE flag back on the .text section, which suggests
that the attributes aren't entirely based on those incoming.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".