Re: Bug with "n" Flag of .section Directive

[Tracy dot Kuhrt at microchip dot com]

Nick,
>
> [This is a resend.  Mail to your direct email address bounced.]

Yes, for some reason my mail server likes to reject e-mails :-(

>
> > 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;
>
> Hmm, perhaps we are looking at different versions of the source code.
> (Also I was using a cross-hosted arm-coff compiler since I do not have
> a sparc-coff environment available).

Yes, we were.  I still have 2.10.1 sources on my machine.  Guess I need to
consider moving on.

> > 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.
>
> I think that this may be the problem.  The flags on disk should be in
> COFF format, not BFD internal format, so bit 1 (0x0002) ought to be
> set, indicating STYP_NOLOAD.  Presumably then the translation from SEC
> flags to STYP flags when the assembler was emitting the foo_n section
> was wrong.

Ah, this makes sense.  I was looking at it the wrong way and thinking that
what the assembler was writing was correct.  It makes sense that this 
should
be outputting the COFF format.

>
> I theory this translation should occur in sec_to_styp_flags() in
> coffcode.h.  (I have not tested any of this), and indeed when I look
> in that file I see a comment that says:
>
>   /* skip LOAD */
>
> Maybe this is the bug.  Maybe this ought to be changed to:
>
>   if ((sec_flags & SEC_LOAD) == 0)
>     styp_flags |= STYP_NOLOAD;

I will give this a try.  It does not look like there is any check in the
current code for this condition.

>
> > 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.
>
> I agree.
>
> I am just wondering why a user would ever want to use the "n" flag on
> its own and not with some other flags ?

I do not know what the reason would be, but you never know what users will
try.  So I thought it was in my best interest to produce the "expected"
results based on the documentation.

Thanks for your help!
Tracy