Re: Named bss sections

Re: Named bss sections

[Christian Iseli]

> I'll ask my question another way :-)  Show me a variable declaration that
> specifies a specific section, but doesn't end up where it belongs and is
> fixed by your patch.

Ah, now I see it.  Turns out my target code uses ENCODE_SECTION_INFO to decide
if it wants to put some small variables in a special section.  The code I wrote
forgot to clear the DECL_COMMON flag after assigning the variable to a section.
Silly me... the patch is not needed now that my other code is corrected.

					Christian

Re: Named bss sections

[Martin Mares]

Hello,

> When you work with embedded targets, it is usually necessary to specify
> where the variables reside in memory.  Most small processors have some
> special mean of accessing certain area of their memory, e.g., the first
> 256 bytes of the RAM (0000 through 00FF) are often seen as "page 0" RAM
> and the processor has special instructions to access that particular RAM area.
> Moreover, most embedded target have I/O ports mapped in RAM at specific address
> and defining those ports using sections is convenient.
> 
> Specifying where data reside in RAM is done through sectionning.  You tell
> the linker to put a particular section of data at a specified RAM address.
> 
> GCC has provision to put global and static variables in user specified sections
> using the section attribute, and though it says in the manual that it should
> only be used for initialized variables, I see no hard reason for this restriction.
> Using the -fno-common flag can partly solve the problem, except that local common
> symbols are still output through the ASM_OUTPUT_LOCAL macro and are implicitely
> forced to the .data section.
> 
> Basically, I want to be able to specify a section for any variable, not only
> initialized ones.  For example, if a variable represents some input port mapped
> in RAM, it would be wrong to have to initialize it to some value.

   In addition to this, it should be also possible to specify a default section
for read-only data (non-writeable strings etc.), probably as a per-function
attribute. This would simplify implementation of automatical discarding of
init code after it has been executed (as used for example in the Linux kernel).

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@gts.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Spelling checkers at maximum!  Fire!"

Re: Named bss sections

[Jeffrey A Law]

  In message < 199709081205.OAA28412@lslsun17.epfl.ch >you write:
  > When you work with embedded targets,
[ ... ]
Yup.  No doubt I deal with this regularly.

  > GCC has provision to put global and static variables in user
  > specified sections using the section attribute, and though it
  > says in the manual that it should only be used for initialized
  > variables, I see no hard reason for this restriction.
Agreed in principle.

  > Basically, I want to be able to specify a section for any variable,
  > not only initialized ones.  For example, if a variable represents
  > some input port mapped in RAM, it would be wrong to have to initialize
  > it to some value.
I'll ask my question another way :-)  Show me a variable declaration that
specifies a specific section, but doesn't end up where it belongs and is
fixed by your patch.

jeff

Re: Named bss sections

[Christian Iseli]

> Exactly what problem are you trying to solve.  As Gavin noted, we
> pulled that patch out as we thought it wasn't strictly necessary.
> 
> If it's necessary on your target, can you please explain why?

When you work with embedded targets, it is usually necessary to specify
where the variables reside in memory.  Most small processors have some
special mean of accessing certain area of their memory, e.g., the first
256 bytes of the RAM (0000 through 00FF) are often seen as "page 0" RAM
and the processor has special instructions to access that particular RAM area.
Moreover, most embedded target have I/O ports mapped in RAM at specific address
and defining those ports using sections is convenient.

Specifying where data reside in RAM is done through sectionning.  You tell
the linker to put a particular section of data at a specified RAM address.

GCC has provision to put global and static variables in user specified sections
using the section attribute, and though it says in the manual that it should
only be used for initialized variables, I see no hard reason for this restriction.
Using the -fno-common flag can partly solve the problem, except that local common
symbols are still output through the ASM_OUTPUT_LOCAL macro and are implicitely
forced to the .data section.

Basically, I want to be able to specify a section for any variable, not only
initialized ones.  For example, if a variable represents some input port mapped
in RAM, it would be wrong to have to initialize it to some value.

					Christian

Re: Named bss sections

[Jeffrey A Law]

  In message < 199709021415.QAA23431@lslsun17.epfl.ch >you write:
  > In the gcc snapshot distributed by Cygnus with the cygwin32 tools, there
  > was support for named bss sections which had been added by someone at
  > Cygnus.  This support has disappeared from egcs.  Was there any reason?
  > If not, the following patch should re-enable this.
  > 
  > Cheers,
  > 					Christian
  > 
  > 
  > 	* varasm.c (assemble_variable): Enable named bss sections.
Exactly what problem are you trying to solve.  As Gavin noted, we
pulled that patch out as we thought it wasn't strictly necessary.

If it's necessary on your target, can you please explain why?


jeff

re: Named bss sections

[Gavin Koch]

Christian Iseli writes:
 > In the gcc snapshot distributed by Cygnus with the cygwin32 tools, there was support
 > for named bss sections which had been added by someone at Cygnus.  This support
 > has disappeared from egcs.  Was there any reason?  If not, the following patch should
 > re-enable this.
 > 
 > Cheers,
 > 					Christian

I'm the origin of this bit of code.  It did not disappear, it was
never there.  It was part of a larger change that I submitted to
gcc2, but this part was not accepted.  This part never made it into
gcc2 sources and thus not into egcs sources.  I have also removed
it from cygnus sources (obviously after the cygwin32 release you got)
in an effort to reduce the differences between gcc2's and cygnus'
sources.

This was a long time ago for me, but I'll add what I remember.  I
had a bug on a particular target, something to do with variables
in named sections.  I wrote a fix for the bug that included the
bit you site.  The bit you site wasn't needed for the target I
cared about, but seemed necessary for some targets I could imagine,
but did not know if they existed.  I can not now remember the details
of the imagined target.  Kenner saw no need for the bit you site, and
though I tried I could not show him it's necessity, so asked me to
resubmit the patch with the bit you site removed.  The fact that
it remained in cygwin sources is actually a mistake on my part.

Presumably you've got a target for which this bit matters.  Good.
You'll need to submit this patch, just like any other patch, along
with some justification. (The fact that it was once part of a cygwin
release certainly ain't enough.) I'm not an authority on what would
constitute justification, Jim will have to comment on that, but I
suspect a testcase and a target description will be enough.
You might also submit it to gcc2, but that's your choice.  In fact
if it's accepted into gcc2 it will, I assume, eventually make it
automatically back into egcs.

Have fun.

                                       -gavin...

Named bss sections

[Christian Iseli]

In the gcc snapshot distributed by Cygnus with the cygwin32 tools, there was support
for named bss sections which had been added by someone at Cygnus.  This support
has disappeared from egcs.  Was there any reason?  If not, the following patch should
re-enable this.

Cheers,
					Christian


	* varasm.c (assemble_variable): Enable named bss sections.

*** varasm.c.orig	Mon Aug 11 17:57:14 1997
--- varasm.c	Tue Sep  2 10:05:38 1997
*************** assemble_variable (decl, top_level, at_e
*** 1350,1355 ****
--- 1350,1360 ----
    /* Handle uninitialized definitions.  */
  
    if ((DECL_INITIAL (decl) == 0 || DECL_INITIAL (decl) == error_mark_node)
+       /* Don't use bss if target supports attribute section and decl wants
+          to be in a specific section.  */
+ #ifdef ASM_OUTPUT_SECTION_NAME
+       && DECL_SECTION_NAME (decl) == NULL_TREE
+ #endif
        /* If the target can't output uninitialized but not common global data
  	 in .bss, then we have to use .data.  */
  #if ! defined (ASM_OUTPUT_BSS) && ! defined (ASM_OUTPUT_ALIGNED_BSS)