Possible Bug with "n" Flag of .section Directive

Tracy.Kuhrt@microchip.com Tracy.Kuhrt@microchip.com
Wed Feb 21 12:21:00 GMT 2001


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






More information about the Binutils mailing list