This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Possible Bug with "n" Flag of .section Directive
- To: nickc at redhat dot com
- Subject: Re: Possible Bug with "n" Flag of .section Directive
- From: Tracy dot Kuhrt at microchip dot com
- Date: Wed, 21 Feb 2001 13:19:34 -0700
- Cc: binutils at sourceware dot cygnus dot com,nickc at cygnus dot com
Nick,
Actually the code in obj-coff.c defaults the flags to SEC_LOAD then when
it sees the "n" flag, it masks out the SEC_LOAD bit with flags &=~
SEC_LOAD;
That was the first place that I looked, as well. When the bfd pointer is
being set up in objdump, the function styp_to_sec_flags in coffcode.h sets the flags to LOAD | ALLOC based on
the flags in the object file, which I found to be 00 00 00 00. The part
that I found strange which made me think that this was a bug was that in
include/coff/internal.h the following #defines exist:
#define STYP_REG (0x0000) /* "regular": allocated,
relocated, loaded */
#define STYP_NOLOAD (0x0002) /* "noload": allocated, relocated,
not loaded */
But in bfd.h the following #defines exist:
#define SEC_NO_FLAGS 0x000
/* Tells the OS to load the section from the file when loading.
This is clear for a .bss section. */
#define SEC_LOAD 0x002
These two seem to be in direct conflict with one another. I would expect
that SEC_NO_FLAGS would mean ~SEC_LOAD (i.e., no load).
The reason I am questioning this is because I am trying to port binutils
to a new architecture. In doing so, I am writing up some test cases, and
I am trying to figure out what the "n" flag is "supposed" to do. Based on
the documentation (as well as the obj-coff.c code) I expected this not to
have a flag of LOAD when I checked the objdump output.
Tracy
Nick Clifton <nickc@redhat.com>
Sent by: nickc@cygnus.com
21-02-2001 12:32 PM
To: Tracy.Kuhrt@microchip.com
cc: binutils@sourceware.cygnus.com
Subject: Re: Possible Bug with "n" Flag of .section Directive
Hi Tracy,
> Given the following .section directive:
> .section foo_n, "n"
>
> The objdump output gives:
>
> foo_n.o: file format coff-sparc
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text 00000000 00000000 00000000 00000000 2**3
> ALLOC, LOAD, CODE
> 1 .data 00000000 00000000 00000000 00000000 2**3
> ALLOC, LOAD, DATA
> 2 .bss 00000000 00000000 00000000 00000000 2**3
> ALLOC
> 3 foo_n 00000000 00000000 00000000 00000000 2**3
> ALLOC, LOAD
>
> The documentation states that the "n" flag means that the section is not
> loaded. The assembler appears to be setting the section's flags
correctly
> in the object file, but when objdump gets ahold of it, it changes the
> flags to be ALLOC, LOAD. It appears that this is happening in the
> function styp_to_sec_flags in coffgen.c. Is this a bug?
Actually I think that you will find that the assembler is setting the
ALLOC and LOAD bits and that objdump is in fact displaying the correct
information.
The reason for this behavior is that the "n" flag removes an
attribute from the section, rather than setting an attribute. The
code in the assembler that parses the .section pseudo op
(obj_coff_section in gas/config/obj-coff.c) starts by setting all the
section flags to zero and then parsing each of the flags in turn. If
no flags were set by the .section directive, then the default
attributes are used instead. In this case the default flags are ALLOC
and LOAD. Since the "n" attribute doe not set a flag, but removes
it, the code thinks that no attributes have been set and so the
defaults are used.
The solution is to use the "b" attribute instead of the "n"
attribute. This will give you an ALLOC'able section which is not
LOAD'able, which is presumably what you want.
Cheers
Nick