Re: Returned mail: Service unavailable

[Nick Clifton <nickc at redhat dot com>]

Hi Tracy,

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

> 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).

In the sources that I was looking at (from an up to day copy of the
binutils CVS repository) the code in obj_coff_section looks like this:

  flags = SEC_NO_FLAGS;

  if (*input_line_pointer == ',')
    {
      ..code to handle flags and add bits to 'flags'
    }

  sec = subseg_new (name, (subsegT) exp);

  oldflags = bfd_get_section_flags (stdoutput, sec);
  if (oldflags == SEC_NO_FLAGS)
    {
      ... code to set 'flags' into the bfd section structure...
    }

So the initial default for me was 0x0 not 0x2...  But anyway, the
basic result of either version of the code is that the flags in bfd
section structure are set to 0.


> 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.

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;



> 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_NOLOAD      (0x0002)
> But in bfd.h the following #defines exist:
> #define SEC_LOAD       0x002
>
> These two seem to be in direct conflict with one another.

They are.

> I would expect that SEC_NO_FLAGS would mean ~SEC_LOAD (i.e., no
> load).

No, I think that the idea of SEC_NO_FLAGS is the value when no (BFD
internal format) flags have been set, ie zero.


> 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 ?

Cheers
        Nick