PATCH: Add .lcomm directive with optional alignment field to x86 port

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PATCH: Add .lcomm directive with optional alignment field to x86 port

Nick Clifton
Hi Guys,

  I am checking in the patch below to add support for the .lcomm
  directive with an optional alignment field to the i386 port of GAS.
  This will allow a suitably modified gcc to generate properly aligned
  static local values.  (I will be submitting a patch to the gcc
  maintainers to make use of this new feature).

Cheers
  Nick

gas/ChangeLog
2008-09-03  Nick Clifton  <[hidden email]>

        * config/tc-i386.c (pe_lcomm_internal): New function.  Allows the
        alignment field of the .lcomm directive to be optional.
        (pe_lcomm): New function.  Pass pe_lcomm_internal to
        s_comm_internal.
        (md_pseudo_table): Implement .lcomm directive for COFF based
        targets.
        * doc/c-i386.texi (i386-Directives): New node.  Used to document
        the .lcomm directive.
       
Index: gas/config/tc-i386.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-i386.c,v
retrieving revision 1.350
diff -c -3 -p -r1.350 tc-i386.c
*** gas/config/tc-i386.c 28 Aug 2008 09:42:11 -0000 1.350
--- gas/config/tc-i386.c 3 Sep 2008 14:00:10 -0000
*************** static const arch_entry cpu_arch[] =
*** 684,689 ****
--- 684,731 ----
      CPU_SSE5_FLAGS },
  };
 
+ /* Like s_lcomm_internal in gas/read.c but the alignment string
+    is allowed to be optional.  */
+
+ static symbolS *
+ pe_lcomm_internal (int needs_align, symbolS *symbolP, addressT size)
+ {
+   addressT align = 0;
+
+   SKIP_WHITESPACE ();
+
+   if (needs_align
+       && *input_line_pointer == ',')
+     {
+       align = parse_align (needs_align - 1);
+      
+       if (align == (addressT) -1)
+ return NULL;
+     }
+   else
+     {
+       if (size >= 8)
+ align = 3;
+       else if (size >= 4)
+ align = 2;
+       else if (size >= 2)
+ align = 1;
+       else
+ align = 0;
+     }
+
+   bss_alloc (symbolP, size, align);
+   return symbolP;
+ }
+
+ void pe_lcomm (int);
+
+ void
+ pe_lcomm (int needs_align)
+ {
+   s_comm_internal (needs_align * 2, pe_lcomm_internal);
+ }
+
  const pseudo_typeS md_pseudo_table[] =
  {
  #if !defined(OBJ_AOUT) && !defined(USE_ALIGN_PTWO)
*************** const pseudo_typeS md_pseudo_table[] =
*** 694,699 ****
--- 736,743 ----
    {"arch", set_cpu_arch, 0},
  #ifndef I386COFF
    {"bss", s_bss, 0},
+ #else
+   {"lcomm", pe_lcomm, 1},
  #endif
    {"ffloat", float_cons, 'f'},
    {"dfloat", float_cons, 'd'},
Index: gas/doc/c-i386.texi
===================================================================
RCS file: /cvs/src/src/gas/doc/c-i386.texi,v
retrieving revision 1.28
diff -c -3 -p -r1.28 c-i386.texi
*** gas/doc/c-i386.texi 2 May 2008 16:53:39 -0000 1.28
--- gas/doc/c-i386.texi 3 Sep 2008 14:00:10 -0000
*************** extending the Intel architecture to 64-b
*** 23,28 ****
--- 23,29 ----
 
  @menu
  * i386-Options::                Options
+ * i386-Directives::             X86 specific directives
  * i386-Syntax::                 AT&T Syntax versus Intel Syntax
  * i386-Mnemonics::              Instruction Naming
  * i386-Regs::                   Register Naming
*************** The @code{.att_syntax} and @code{.intel_
*** 193,198 ****
--- 194,224 ----
 
  @end table
 
+ @node i386-Directives
+ @section x86 specific Directives
+
+ @cindex machine directives, x86
+ @cindex x86 machine directives
+ @table @code
+
+ @cindex @code{lcomm} directive, COFF
+ @item .lcomm @var{symbol} , @var{length}[, @var{alignment}]
+ Reserve @var{length} (an absolute expression) bytes for a local common
+ denoted by @var{symbol}.  The section and value of @var{symbol} are
+ those of the new local common.  The addresses are allocated in the bss
+ section, so that at run-time the bytes start off zeroed.  @var{Symbol}
+ is not declared global (@pxref{Global,,@code{.global}}), so is normally
+ not visible to @code{@value{LD}}.  The optional third parameter,
+ @var{alignment}, specifies the desired alignment of the symbol in the
+ bss section.
+
+ This directive is only available for COFF based x86 targets.
+
+ @c FIXME: Document other x86 specific directives ?  Eg: .code16gcc,
+ @c .largecomm
+
+ @end table
+
  @node i386-Syntax
  @section AT&T Syntax versus Intel Syntax
 
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add .lcomm directive with optional alignment field to x86 port

H.J. Lu-30
On Wed, Sep 3, 2008 at 7:01 AM, Nick Clifton <[hidden email]> wrote:

> Hi Guys,
>
>  I am checking in the patch below to add support for the .lcomm
>  directive with an optional alignment field to the i386 port of GAS.
>  This will allow a suitably modified gcc to generate properly aligned
>  static local values.  (I will be submitting a patch to the gcc
>  maintainers to make use of this new feature).
>
> Cheers
>  Nick
>
> gas/ChangeLog
> 2008-09-03  Nick Clifton  <[hidden email]>
>
>        * config/tc-i386.c (pe_lcomm_internal): New function.  Allows the
>        alignment field of the .lcomm directive to be optional.
>        (pe_lcomm): New function.  Pass pe_lcomm_internal to
>        s_comm_internal.
>        (md_pseudo_table): Implement .lcomm directive for COFF based
>        targets.
>        * doc/c-i386.texi (i386-Directives): New node.  Used to document
>        the .lcomm directive.
>
> Index: gas/config/tc-i386.c
> ===================================================================
> RCS file: /cvs/src/src/gas/config/tc-i386.c,v
> retrieving revision 1.350
> diff -c -3 -p -r1.350 tc-i386.c
> *** gas/config/tc-i386.c        28 Aug 2008 09:42:11 -0000      1.350
> --- gas/config/tc-i386.c        3 Sep 2008 14:00:10 -0000
> *************** static const arch_entry cpu_arch[] =
> *** 684,689 ****
> --- 684,731 ----
>      CPU_SSE5_FLAGS },
>  };
>
> + /* Like s_lcomm_internal in gas/read.c but the alignment string
> +    is allowed to be optional.  */
> +
> + static symbolS *
> + pe_lcomm_internal (int needs_align, symbolS *symbolP, addressT size)
> + {
> +   addressT align = 0;
> +
> +   SKIP_WHITESPACE ();
> +
> +   if (needs_align
> +       && *input_line_pointer == ',')
> +     {
> +       align = parse_align (needs_align - 1);
> +
> +       if (align == (addressT) -1)
> +       return NULL;
> +     }
> +   else
> +     {
> +       if (size >= 8)
> +       align = 3;
> +       else if (size >= 4)
> +       align = 2;
> +       else if (size >= 2)
> +       align = 1;
> +       else
> +       align = 0;
> +     }
> +
> +   bss_alloc (symbolP, size, align);
> +   return symbolP;
> + }
> +
> + void pe_lcomm (int);

Can it be static? Can we define pe_lcomm and pe_lcomm_internal
for I386COFF only?

H.J.
---

> +
> + void
> + pe_lcomm (int needs_align)
> + {
> +   s_comm_internal (needs_align * 2, pe_lcomm_internal);
> + }
> +
>  const pseudo_typeS md_pseudo_table[] =
>  {
>  #if !defined(OBJ_AOUT) && !defined(USE_ALIGN_PTWO)
> *************** const pseudo_typeS md_pseudo_table[] =
> *** 694,699 ****
> --- 736,743 ----
>    {"arch", set_cpu_arch, 0},
>  #ifndef I386COFF
>    {"bss", s_bss, 0},
> + #else
> +   {"lcomm", pe_lcomm, 1},
>  #endif
>    {"ffloat", float_cons, 'f'},
>    {"dfloat", float_cons, 'd'},
> Index: gas/doc/c-i386.texi
> ===================================================================
> RCS file: /cvs/src/src/gas/doc/c-i386.texi,v
> retrieving revision 1.28
> diff -c -3 -p -r1.28 c-i386.texi
> *** gas/doc/c-i386.texi 2 May 2008 16:53:39 -0000       1.28
> --- gas/doc/c-i386.texi 3 Sep 2008 14:00:10 -0000
> *************** extending the Intel architecture to 64-b
> *** 23,28 ****
> --- 23,29 ----
>
>  @menu
>  * i386-Options::                Options
> + * i386-Directives::             X86 specific directives
>  * i386-Syntax::                 AT&T Syntax versus Intel Syntax
>  * i386-Mnemonics::              Instruction Naming
>  * i386-Regs::                   Register Naming
> *************** The @code{.att_syntax} and @code{.intel_
> *** 193,198 ****
> --- 194,224 ----
>
>  @end table
>
> + @node i386-Directives
> + @section x86 specific Directives
> +
> + @cindex machine directives, x86
> + @cindex x86 machine directives
> + @table @code
> +
> + @cindex @code{lcomm} directive, COFF
> + @item .lcomm @var{symbol} , @var{length}[, @var{alignment}]
> + Reserve @var{length} (an absolute expression) bytes for a local common
> + denoted by @var{symbol}.  The section and value of @var{symbol} are
> + those of the new local common.  The addresses are allocated in the bss
> + section, so that at run-time the bytes start off zeroed.  @var{Symbol}
> + is not declared global (@pxref{Global,,@code{.global}}), so is normally
> + not visible to @code{@value{LD}}.  The optional third parameter,
> + @var{alignment}, specifies the desired alignment of the symbol in the
> + bss section.
> +
> + This directive is only available for COFF based x86 targets.
> +
> + @c FIXME: Document other x86 specific directives ?  Eg: .code16gcc,
> + @c .largecomm
> +
> + @end table
> +
>  @node i386-Syntax
>  @section AT&T Syntax versus Intel Syntax
>
>



--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add .lcomm directive with optional alignment field to x86 port

Andreas Schwab
In reply to this post by Nick Clifton
Nick Clifton <[hidden email]> writes:

> + @cindex @code{lcomm} directive, COFF
> + @item .lcomm @var{symbol} , @var{length}[, @var{alignment}]
> + Reserve @var{length} (an absolute expression) bytes for a local common
> + denoted by @var{symbol}.  The section and value of @var{symbol} are
> + those of the new local common.  The addresses are allocated in the bss
> + section, so that at run-time the bytes start off zeroed.  @var{Symbol}
> + is not declared global (@pxref{Global,,@code{.global}}), so is normally
> + not visible to @code{@value{LD}}.

Please reorder the last sentence to avoid having to capitalize
@var{symbol}.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add .lcomm directive with optional alignment field to x86 port

Nick Clifton
Hi Andreas, Hi H.J.


> Please reorder the last sentence to avoid having to capitalize
> @var{symbol}.

> Can it be static? Can we define pe_lcomm and pe_lcomm_internal
> for I386COFF only?

Of course.  I have checked in the attached patch to address both of
these points.

Cheers
   Nick

i386_lcomm.gas.patch.2 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add .lcomm directive with optional alignment field to x86 port

Brian Dessent
In reply to this post by Nick Clifton
Nick Clifton wrote:

>   This will allow a suitably modified gcc to generate properly aligned
>   static local values.  (I will be submitting a patch to the gcc
>   maintainers to make use of this new feature).

Excellent, that sounds like a proper fix for
<http://gcc.gnu.org/PR37216>.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add .lcomm directive with optional alignment field to x86 port

Danny Smith-5
On Thu, Sep 4, 2008 at 6:56 AM, Brian Dessent <[hidden email]> wrote:

> Nick Clifton wrote:
>
>>   This will allow a suitably modified gcc to generate properly aligned
>>   static local values.  (I will be submitting a patch to the gcc
>>   maintainers to make use of this new feature).
>
> Excellent, that sounds like a proper fix for
> <http://gcc.gnu.org/PR37216>.
>
> Brian
>
Not really. That bug is about global symbols.
Danny
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add .lcomm directive with optional alignment field to x86 port

Brian Dessent
Danny Smith wrote:

> > Excellent, that sounds like a proper fix for
> > <http://gcc.gnu.org/PR37216>.
>
> Not really. That bug is about global symbols.

Right, but as I see it they're two instances of the same problem: how to
communicate an alignment of a common symbol to the assembler.  I just
figured that if .lcomm can be implemented to take an alignment then the
same approach can be used with .comm.

Brian