variable-attributes.html

自己收集的linux入门到学懂高级编程书集 包括linux程序设计第三版

immediately follows <code>a</code>:

     <pre class="smallexample">          struct foo
          {
            char a;
            int x[2] __attribute__ ((packed));
          };
          </pre>

     <br><dt><code>section ("</code><var>section-name</var><code>")</code>
     <dd>Normally, the compiler places the objects it generates in sections like
<code>data</code> and <code>bss</code>.  Sometimes, however, you need additional sections,
or you need certain particular variables to appear in special sections,
for example to map to special hardware.  The <code>section</code>
attribute specifies that a variable (or function) lives in a particular
section.  For example, this small program uses several specific section names:

     <pre class="smallexample">          struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
          struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
          char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
          int init_data __attribute__ ((section ("INITDATA"))) = 0;
          
          main()
          {
            /* Initialize stack pointer */
            init_sp (stack + sizeof (stack));
          
            /* Initialize initialized data */
            memcpy (&amp;init_data, &amp;data, &amp;edata - &amp;data);
          
            /* Turn on the serial ports */
            init_duart (&amp;a);
            init_duart (&amp;b);
          }
          </pre>

     <p>Use the <code>section</code> attribute with an <em>initialized</em> definition
of a <em>global</em> variable, as shown in the example.  GCC issues
a warning and otherwise ignores the <code>section</code> attribute in
uninitialized variable declarations.

     <p>You may only use the <code>section</code> attribute with a fully initialized
global definition because of the way linkers work.  The linker requires
each object be defined once, with the exception that uninitialized
variables tentatively go in the <code>common</code> (or <code>bss</code>) section
and can be multiply "defined".  You can force a variable to be
initialized with the <code>-fno-common</code> flag or the <code>nocommon</code>
attribute.

     <p>Some file formats do not support arbitrary sections so the <code>section</code>
attribute is not available on all platforms. 
If you need to map the entire contents of a module to a particular
section, consider using the facilities of the linker instead.

     <br><dt><code>shared</code>
     <dd>On Microsoft Windows, in addition to putting variable definitions in a named
section, the section can also be shared among all running copies of an
executable or DLL.  For example, this small program defines shared data
by putting it in a named section <code>shared</code> and marking the section
shareable:

     <pre class="smallexample">          int foo __attribute__((section ("shared"), shared)) = 0;
          
          int
          main()
          {
            /* Read and write foo.  All running
               copies see the same value.  */
            return 0;
          }
          </pre>

     <p>You may only use the <code>shared</code> attribute along with <code>section</code>
attribute with a fully initialized global definition because of the way
linkers work.  See <code>section</code> attribute for more information.

     <p>The <code>shared</code> attribute is only available on Microsoft Windows.

     <br><dt><code>tls_model ("</code><var>tls_model</var><code>")</code>
     <dd>The <code>tls_model</code> attribute sets thread-local storage model
(see <a href="Thread-Local.html#Thread-Local">Thread-Local</a>) of a particular <code>__thread</code> variable,
overriding <code>-ftls-model=</code> command line switch on a per-variable
basis. 
The <var>tls_model</var> argument should be one of <code>global-dynamic</code>,
<code>local-dynamic</code>, <code>initial-exec</code> or <code>local-exec</code>.

     <p>Not all targets support this attribute.

     <br><dt><code>transparent_union</code>
     <dd>This attribute, attached to a function parameter which is a union, means
that the corresponding argument may have the type of any union member,
but the argument is passed as if its type were that of the first union
member.  For more details see See <a href="Type-Attributes.html#Type%20Attributes">Type Attributes</a>.  You can also use
this attribute on a <code>typedef</code> for a union data type; then it
applies to all function parameters with that type.

     <br><dt><code>unused</code>
     <dd>This attribute, attached to a variable, means that the variable is meant
to be possibly unused.  GCC will not produce a warning for this
variable.

     <br><dt><code>vector_size (</code><var>bytes</var><code>)</code>
     <dd>This attribute specifies the vector size for the variable, measured in
bytes.  For example, the declaration:

     <pre class="smallexample">          int foo __attribute__ ((vector_size (16)));
          </pre>

     <p>causes the compiler to set the mode for <code>foo</code>, to be 16 bytes,
divided into <code>int</code> sized units.  Assuming a 32-bit int (a vector of
4 units of 4 bytes), the corresponding mode of <code>foo</code> will be V4SI.

     <p>This attribute is only applicable to integral and float scalars,
although arrays, pointers, and function return values are allowed in
conjunction with this construct.

     <p>Aggregates with this attribute are invalid, even if they are of the same
size as a corresponding scalar.  For example, the declaration:

     <pre class="smallexample">          struct S { int a; };
          struct S  __attribute__ ((vector_size (16))) foo;
          </pre>

     <p>is invalid even if the size of the structure is the same as the size of
the <code>int</code>.

     <br><dt><code>weak</code>
     <dd>The <code>weak</code> attribute is described in See <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>.

     <br><dt><code>dllimport</code>
     <dd>The <code>dllimport</code> attribute is described in See <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>.

     <br><dt><code>dlexport</code>
     <dd>The <code>dllexport</code> attribute is described in See <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>.

   </dl>

<h3 class="subsection">M32R/D Variable Attributes</h4>

<p>One attribute is currently defined for the M32R/D.

     <dl>
<dt><code>model (</code><var>model-name</var><code>)</code>
     <dd>Use this attribute on the M32R/D to set the addressability of an object. 
The identifier <var>model-name</var> is one of <code>small</code>, <code>medium</code>,
or <code>large</code>, representing each of the code models.

     <p>Small model objects live in the lower 16MB of memory (so that their
addresses can be loaded with the <code>ld24</code> instruction).

     <p>Medium and large model objects may live anywhere in the 32-bit address space
(the compiler will generate <code>seth/add3</code> instructions to load their
addresses). 
</dl>

<h3 class="subsection">i386 Variable Attributes</h4>

<p>Two attributes are currently defined for i386 configurations:
<code>ms_struct</code> and <code>gcc_struct</code>

     <dl>
<dt><code>ms_struct</code>
     <dd><dt><code>gcc_struct</code>
     <dd>

     <p>If <code>packed</code> is used on a structure, or if bit-fields are used
it may be that the Microsoft ABI packs them differently
than GCC would normally pack them.  Particularly when moving packed
data between functions compiled with GCC and the native Microsoft compiler
(either via function call or as data in a file), it may be necessary to access
either format.

     <p>Currently <code>-m[no-]ms-bitfields</code> is provided for the Microsoft Windows X86
compilers to match the native Microsoft compiler. 
</dl>

   </body></html>