From: Nick Clifton <nickc@cygnus.com>
To: snowball3@bigfoot.com
Cc: binutils@sourceware.cygnus.com
Subject: Re: Minor fix to COFF .section change
Date: Mon, 03 Jul 2000 10:42:00 -0000 [thread overview]
Message-ID: <200007031742.KAA27100@elmo.cygnus.com> (raw)
Hi Mark,
: There seems to be another problem in my opinion as a consequence of
: the current default.
:
: .section .foo,"w"
: .section .foo2,"d"
:
: produces:
:
: 3 .foo 00000000 00000000 00000000 00000000 2**2
: ALLOC, LOAD, CODE
: 4 .foo2 00000000 00000000 00000000 00000000 2**2
: ALLOC, LOAD, DATA
:
: The !BFD version handles 'w' and 'd' the same way, I think the BFD version
: should too. Thoughts?
Hmm, well I agree that .foo ought to be a DATA section not a CODE
section, so that in this case they ought to end up with the same
attributes.
Looking at the source in obj-coff.c it seems that "d" type sections
explicitly have SEC_DATA and SEC_LOAD set, whereas "w" sections do
not. I am not sure why this should be, although I suspect it is
because the m88k does not default to setting these attributes for its
sections.
I assume that your proposed patch fixes this problem as well ?
: > I'm concerned that there may be software out there that may
: > create a section, expecting it to be executable (the old way) but
: > finding it's not (the new way).
:
: I do believe the proposed new default matches the documentation, but
; I see your point. I looked through the GCC config files that define
: ASM_OUTPUT_SECTION, but it wasn't much help because they all use
: pretty much the same in always adding the attribute so there's never
: a doubt about what's intended. DJGPP should do the same in gcc 3.0.
:
: Anyway, as I see it there are several ways to go:
:
: 1. Go ahead and change the default attribute to match the docs.
:
: 2. Go with #1, but if it turns out to be a problem for a target, let
: it default to code.
: 2a. Let a target choose between defaulting to code or to data.
:
: 3. Recognize .eh_frame (as the .section doc allows) and set SEC_DATA
: for it.
:
: My preference is for door #2. Door #3 goes in the direction of
: automatically setting the right attributes for every special section
: there is.
I like 2/2a too. Can you try generating a new version of the patch
that creates a new target macro (eg TC_COFF_DEFAULT_SECTION_ATTRIBUTES)
which if not defined defaults to SEC_LOAD | SEC_DATA, and which then
uses this macro in obj_coff_section(). If you can also generate a
paragraph to go into doc/internals.texi describing this new macro,
that would be great.
Cheers
Nick
next reply other threads:[~2000-07-03 10:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-03 10:42 Nick Clifton [this message]
2000-07-03 20:28 ` Mark E.
-- strict thread matches above, loose matches on Subject: below --
2000-07-05 14:47 Nick Clifton
2000-07-02 14:22 Mark E.
2000-07-02 7:10 Mark E.
2000-07-01 18:39 Mark E.
2000-07-01 20:14 ` DJ Delorie
2000-07-02 7:08 ` Mark E.
2000-07-02 7:08 ` Mark E.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200007031742.KAA27100@elmo.cygnus.com \
--to=nickc@cygnus.com \
--cc=binutils@sourceware.cygnus.com \
--cc=snowball3@bigfoot.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).