This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH - darwin] PR target/25376
- From: Roger Sayle <roger at eyesopen dot com>
- To: Josh Conner <jconner at apple dot com>
- Cc: Geoffrey Keating <geoffk at geoffk dot org>, Mike Stump <mrs at apple dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 5 Feb 2006 08:11:36 -0700 (MST)
- Subject: Re: [PATCH - darwin] PR target/25376
Hi Josh,
On Fri, 3 Feb 2006, Josh Conner wrote:
> target-supports.exp was incorrectly identifying darwin compilers as not
> supporting named sections because they didn't compile this code:
>
> int __attribute__ ((section("whatever"))) foo;
>
> In fact, named sections are supported by the darwin compiler, but
> because "whatever" isn't a valid section identifier, the assembler was
> rejecting it.
I'm just trying to understand some of the issues... So I was
wondering why "whatever" isn't a valid section identifier on darwin,
and which identifiers are valid?
For example, it seems curious why we'd compile this test without
assembling it. Perhaps the compiler should issue a diagnostic if
the __attribute__ ((section ...)) name isn't valid, or perhaps this
code should be mangling the name so that it becomes valid.
That a user can't compile the code above, indicates that darwin has
diminished functionality, though it isn't clear whether this is a
restriction of the OS or a limition of the tool chain. Perhaps we
need a finer distinction such as SUPPORTS_ARBITRARY_NAMED_SECTIONS?
Perhaps based upon compile vs. link testing.
> * gcc/varasm.c (function_section) Check for section name before
> calling select_section on targets that define
> USE_SELECT_SECTION_FOR_FUNCTIONS. On other targets, use
> unlikely_text_section instead of named_section if
> first_function_block_is_cold.
This should start "* varasm.c (function_section): Check for ..." as
varasm.c is in the same directory as the ChangeLog, and the colon is
required after the file location.
This isn't a review. Other maintainers are better qualified to
judge the merits of this patch, this is just an asynchronous
(non-blocking) discussion to help bring me up to speed.
Thanks in advance,
Roger
--