Mail Archives: cygwin/1997/07/17/09:50:29
Date: Wed, 16 Jul 1997 15:22:21 +0100
From: Jon Thackray <jont AT harlequin DOT co DOT 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>
<199707161317 DOT OAA27491 AT zaphod DOT long DOT harlequin DOT co DOT uk>
Sender: owner-gnu-win32 AT cygnus DOT com
Precedence: bulk
Jon Thackray writes:
> 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.
Further investigation suggests there is a bug in bfd/peicode.h In
^^^^^^^^
Such kindness :-) The FIXME is I think correct. That is, I'm pretty sure
the ppc port (which is where the comment originated) only supports those
section attributes that map to section attributes directly supported in
bfd as it piggybacked on top of the existing PE port for the x86.
It of course could be extended. One would (my guess) have to attach to the
section a piece of memory to hold the encodings when being swapped in, and
make sure they were propagated as necessary to be present when swapping
headers out.
--krk.
--
Kim Knuttila | Speaking for himself as always.
Cygnus Solutions | Woof.
| I'm not easy... but I can be tricked.
-
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".
- Raw text -