Multiple sections with same name don't work

Multiple sections with same name don't work

[H. J. Lu]

The current assembler still doesn't support multiple section with
the same section name:

[hjl@gnu comdat-1]$ cat foo.s
        .text
.L1:
        .align 4
.L2:
.L3:
        .section        .data,"",@progbits
        .long   .L3-.L1
        .section        .text,"axG",@progbits,foo,comdat
[hjl@gnu comdat-1]$ gcc -c foo.s
foo.s: Assembler messages:
foo.s:7: Error: can't resolve `.text' {.text section} - `.L1' {.text section}


H.J.

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

On Fri, Apr 30, 2004 at 04:01:29PM -0700, H. J. Lu wrote:
> On Fri, Apr 30, 2004 at 03:12:44PM -0700, H. J. Lu wrote:
> > The current assembler still doesn't support multiple section with
> > the same section name:
> > 
> > [hjl@gnu comdat-1]$ cat foo.s
> >         .text
> > .L1:
> >         .align 4
> > .L2:
> > .L3:
> >         .section        .data,"",@progbits
> >         .long   .L3-.L1
> >         .section        .text,"axG",@progbits,foo,comdat
> > [hjl@gnu comdat-1]$ gcc -c foo.s
> > foo.s: Assembler messages:
> > foo.s:7: Error: can't resolve `.text' {.text section} - `.L1' {.text section}
> > 
> > 
> 
> This patch seems to work for me. I don't quite understand why we call
> symbol_set_bfdsym here if we only want to add the symbol to the
> symbol table.
> 
> 

It is not enough. Now I got

[hjl@gnu-psc comdat-2]$ gcc -c bar.s
bar.s: Assembler messages:
bar.s:14: Error: can't resolve `.text' {.text section} - `.LFB359' {.text
section}
[hjl@gnu-psc comdat-2]$ cat bar.s
        .section        .text,"axG",@progbits,foo,comdat
.LFB359:
.L46:
        jbe     .L46
.LFE359:
        .section        .text,"axG",@progbits,bar,comdat
.LFB401:
.L514:
        jmp     .L514
.LFE401:
        .section        .eh_frame,"a",@progbits
.Lframe1:
.LSCIE1:
        .long   .LFE359-.LFB359
.LASFDE101:
        .long   .LFE401-.LFB401
.LEFDE101:
        .section        .data,"awG",@progbits,foobar,comdat


H.J.

Re: PATCH: Multiple sections with same name don't work

[Alan Modra]

On Fri, Apr 30, 2004 at 05:36:37PM -0700, H. J. Lu wrote:
> bar.s:14: Error: can't resolve `.text' {.text section} - `.LFB359' {.text
> section}

I expect you need to rewrite all the parts of gas dealing with section
symbols.  :-(  The assumption is that global symbols have unique names,
which is no longer true.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PATCH: Multiple sections with same name don't work

[Alan Modra]

On Sat, May 01, 2004 at 12:01:36PM +0930, Alan Modra wrote:
> On Fri, Apr 30, 2004 at 05:36:37PM -0700, H. J. Lu wrote:
> > bar.s:14: Error: can't resolve `.text' {.text section} - `.LFB359' {.text
> > section}
> 
> I expect you need to rewrite all the parts of gas dealing with section
> symbols.  :-(  The assumption is that global symbols have unique names,
> which is no longer true.

Actually, it is probably a mistake to try to support multiple sections
of the same name in gas.  For instance, if you have two .text sections,
how is gas supposed to evaluate ".long .text" ?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

On Sat, May 01, 2004 at 12:29:13PM +0930, Alan Modra wrote:
> On Sat, May 01, 2004 at 12:01:36PM +0930, Alan Modra wrote:
> > On Fri, Apr 30, 2004 at 05:36:37PM -0700, H. J. Lu wrote:
> > > bar.s:14: Error: can't resolve `.text' {.text section} - `.LFB359' {.text
> > > section}
> > 
> > I expect you need to rewrite all the parts of gas dealing with section
> > symbols.  :-(  The assumption is that global symbols have unique names,
> > which is no longer true.
> 
> Actually, it is probably a mistake to try to support multiple sections
> of the same name in gas.  For instance, if you have two .text sections,
> how is gas supposed to evaluate ".long .text" ?
> 

Will that be generated by compiler? If not, we can issue an error.


H.J.

Re: PATCH: Multiple sections with same name don't work

[Alan Modra]

On Fri, Apr 30, 2004 at 08:43:00PM -0700, H. J. Lu wrote:
> On Sat, May 01, 2004 at 12:29:13PM +0930, Alan Modra wrote:
> > Actually, it is probably a mistake to try to support multiple sections
> > of the same name in gas.  For instance, if you have two .text sections,
> > how is gas supposed to evaluate ".long .text" ?
> 
> Will that be generated by compiler? If not, we can issue an error.

The real question is: Do we need multiple sections of the same name
in assembly files?  I don't think we do.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

On Sat, May 01, 2004 at 01:55:06PM +0930, Alan Modra wrote:
> On Fri, Apr 30, 2004 at 08:43:00PM -0700, H. J. Lu wrote:
> > On Sat, May 01, 2004 at 12:29:13PM +0930, Alan Modra wrote:
> > > Actually, it is probably a mistake to try to support multiple sections
> > > of the same name in gas.  For instance, if you have two .text sections,
> > > how is gas supposed to evaluate ".long .text" ?
> > 
> > Will that be generated by compiler? If not, we can issue an error.
> 
> The real question is: Do we need multiple sections of the same name
> in assembly files?  I don't think we do.

The input file may not. But the output should. Otherwise, we have to
change the linker to support section group since it has

  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }



H.J.

Re: PATCH: Multiple sections with same name don't work

[Zack Weinberg]

Alan Modra <amodra@bigpond.net.au> writes:

> On Fri, Apr 30, 2004 at 08:43:00PM -0700, H. J. Lu wrote:
>> On Sat, May 01, 2004 at 12:29:13PM +0930, Alan Modra wrote:
>> > Actually, it is probably a mistake to try to support multiple sections
>> > of the same name in gas.  For instance, if you have two .text sections,
>> > how is gas supposed to evaluate ".long .text" ?
>> 
>> Will that be generated by compiler? If not, we can issue an error.
>
> The real question is: Do we need multiple sections of the same name
> in assembly files?  I don't think we do.

I need them in order to generate COMDAT sections compatible with the
HPUX linker.  gcc might emit e.g.

     .section .text 
     # non-COMDAT code  ...

     .section .text,"G",symbol_name,comdat
     # code for symbol_name ...

     .section .eh_frame
     # non-COMDAT unwind info ...

     .section .eh_frame,"G",symbol_name,comdat
     # unwind info for symbol_name ...

zw

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> > On Fri, Apr 30, 2004 at 08:43:00PM -0700, H. J. Lu wrote:
> >> On Sat, May 01, 2004 at 12:29:13PM +0930, Alan Modra wrote:
> >> > Actually, it is probably a mistake to try to support multiple sections
> >> > of the same name in gas.  For instance, if you have two .text sections,
> >> > how is gas supposed to evaluate ".long .text" ?
> >> 
> >> Will that be generated by compiler? If not, we can issue an error.
> >
> > The real question is: Do we need multiple sections of the same name
> > in assembly files?  I don't think we do.
> 
> I need them in order to generate COMDAT sections compatible with the
> HPUX linker.  gcc might emit e.g.
> 
>      .section .text 
>      # non-COMDAT code  ...
> 
>      .section .text,"G",symbol_name,comdat
>      # code for symbol_name ...
> 
>      .section .eh_frame
>      # non-COMDAT unwind info ...
> 
>      .section .eh_frame,"G",symbol_name,comdat
>      # unwind info for symbol_name ...
> 

I am testing this patch now.


H.J.

[-- Attachment #2: gas-elf-same-2.patch --]
[-- Type: text/plain, Size: 502 bytes --]

2004-04-30  H.J. Lu  <hongjiu.lu@intel.com>

	* symbols.c (symbol_set_bfdsym): Don't reset BFD section symbol.

--- gas/symbols.c.same	2003-12-04 10:43:25.000000000 -0800
+++ gas/symbols.c	2004-04-30 22:45:18.000000000 -0700
@@ -2260,7 +2260,8 @@ symbol_set_bfdsym (symbolS *s, asymbol *
 {
   if (LOCAL_SYMBOL_CHECK (s))
     s = local_symbol_convert ((struct local_symbol *) s);
-  s->bsym = bsym;
+  if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
+    s->bsym = bsym;
 }
 
 #endif /* BFD_ASSEMBLER */

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On Fri, Apr 30, 2004 at 10:50:08PM -0700, H. J. Lu wrote:
> On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
> > Alan Modra <amodra@bigpond.net.au> writes:
> > 
> > > On Fri, Apr 30, 2004 at 08:43:00PM -0700, H. J. Lu wrote:
> > >> On Sat, May 01, 2004 at 12:29:13PM +0930, Alan Modra wrote:
> > >> > Actually, it is probably a mistake to try to support multiple sections
> > >> > of the same name in gas.  For instance, if you have two .text sections,
> > >> > how is gas supposed to evaluate ".long .text" ?
> > >> 
> > >> Will that be generated by compiler? If not, we can issue an error.
> > >
> > > The real question is: Do we need multiple sections of the same name
> > > in assembly files?  I don't think we do.
> > 
> > I need them in order to generate COMDAT sections compatible with the
> > HPUX linker.  gcc might emit e.g.
> > 
> >      .section .text 
> >      # non-COMDAT code  ...
> > 
> >      .section .text,"G",symbol_name,comdat
> >      # code for symbol_name ...
> > 
> >      .section .eh_frame
> >      # non-COMDAT unwind info ...
> > 
> >      .section .eh_frame,"G",symbol_name,comdat
> >      # unwind info for symbol_name ...
> > 
> 
> I am testing this patch now.
> 
> 
> H.J.

> 2004-04-30  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* symbols.c (symbol_set_bfdsym): Don't reset BFD section symbol.
> 

This patch is not enough. Here is an updated one.


H.J.

[-- Attachment #2: gas-elf-same-3.patch --]
[-- Type: text/plain, Size: 1162 bytes --]

2004-04-30  H.J. Lu  <hongjiu.lu@intel.com>

	* subsegs.c (section_symbol): Create a new section symbol if
	the existing one doesn't match.

	* symbols.c (symbol_set_bfdsym): Don't reset BFD section symbol.

--- gas/subsegs.c.same	2003-12-04 10:43:25.000000000 -0800
+++ gas/subsegs.c	2004-04-30 23:51:32.000000000 -0700
@@ -524,7 +524,9 @@ section_symbol (segT sec)
   else
     {
       s = symbol_find_base (sec->symbol->name, 0);
-      if (s == NULL)
+      /* We have to make sure it is the right symbol when we have
+	 multiple sections with the same section name.  */
+      if (s == NULL || S_GET_SEGMENT (s) != sec)
 	s = symbol_new (sec->symbol->name, sec, 0, &zero_address_frag);
       else
 	{
--- gas/symbols.c.same	2003-12-04 10:43:25.000000000 -0800
+++ gas/symbols.c	2004-04-30 23:52:45.000000000 -0700
@@ -2260,7 +2260,9 @@ symbol_set_bfdsym (symbolS *s, asymbol *
 {
   if (LOCAL_SYMBOL_CHECK (s))
     s = local_symbol_convert ((struct local_symbol *) s);
-  s->bsym = bsym;
+  /* Don't reset it if it is already a BFD section symbol.  */
+  if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
+    s->bsym = bsym;
 }
 
 #endif /* BFD_ASSEMBLER */

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> > On Fri, Apr 30, 2004 at 08:43:00PM -0700, H. J. Lu wrote:
> >> On Sat, May 01, 2004 at 12:29:13PM +0930, Alan Modra wrote:
> >> > Actually, it is probably a mistake to try to support multiple sections
> >> > of the same name in gas.  For instance, if you have two .text sections,
> >> > how is gas supposed to evaluate ".long .text" ?
> >> 
> >> Will that be generated by compiler? If not, we can issue an error.
> >
> > The real question is: Do we need multiple sections of the same name
> > in assembly files?  I don't think we do.
> 
> I need them in order to generate COMDAT sections compatible with the
> HPUX linker.  gcc might emit e.g.
> 
>      .section .text 
>      # non-COMDAT code  ...
> 
>      .section .text,"G",symbol_name,comdat
>      # code for symbol_name ...
> 
>      .section .eh_frame
>      # non-COMDAT unwind info ...
> 
>      .section .eh_frame,"G",symbol_name,comdat
>      # unwind info for symbol_name ...

I am looking forward to that day :-). I will do my best to make sure
assembler and linker will handle them correctly.


H.J.

Re: PATCH: Multiple sections with same name don't work

[Alan Modra]

On Sat, May 01, 2004 at 12:06:18AM -0700, H. J. Lu wrote:
> On Fri, Apr 30, 2004 at 10:50:08PM -0700, H. J. Lu wrote:
> > On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
> > > Alan Modra <amodra@bigpond.net.au> writes:
> > > > The real question is: Do we need multiple sections of the same name
> > > > in assembly files?  I don't think we do.
> > > 
> > > I need them in order to generate COMDAT sections compatible with the
> > > HPUX linker.  gcc might emit e.g.
> > > 
> > >      .section .text 
> > >      # non-COMDAT code  ...
> > > 
> > >      .section .text,"G",symbol_name,comdat
> > >      # code for symbol_name ...

Hmm, it wouldn't be much harder to use

     .section .text.symbol_name,"G",symbol_name,comdat
     # code for symbol_name ...

I fear HJ is going to be repeating the following a few more times.. 

> This patch is not enough. Here is an updated one.

[snip]
> +  /* Don't reset it if it is already a BFD section symbol.  */
> +  if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
> +    s->bsym = bsym;

This is a useless comment.  It just says what anyone can see from the
next line of code.  It would be better to say _why_ it is necessary to
treat section symbols specially.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

On Sun, May 02, 2004 at 12:14:39AM +0930, Alan Modra wrote:
> On Sat, May 01, 2004 at 12:06:18AM -0700, H. J. Lu wrote:
> > On Fri, Apr 30, 2004 at 10:50:08PM -0700, H. J. Lu wrote:
> > > On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
> > > > Alan Modra <amodra@bigpond.net.au> writes:
> > > > > The real question is: Do we need multiple sections of the same name
> > > > > in assembly files?  I don't think we do.
> > > > 
> > > > I need them in order to generate COMDAT sections compatible with the
> > > > HPUX linker.  gcc might emit e.g.
> > > > 
> > > >      .section .text 
> > > >      # non-COMDAT code  ...
> > > > 
> > > >      .section .text,"G",symbol_name,comdat
> > > >      # code for symbol_name ...
> 
> Hmm, it wouldn't be much harder to use
> 
>      .section .text.symbol_name,"G",symbol_name,comdat
>      # code for symbol_name ...
> 
> I fear HJ is going to be repeating the following a few more times.. 
> 

I am ready for it.

> > This patch is not enough. Here is an updated one.
> 
> [snip]
> > +  /* Don't reset it if it is already a BFD section symbol.  */
> > +  if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
> > +    s->bsym = bsym;

This patch is no longer needed for multiple section with the same
name. The section_symbol patch is enough.

> 
> This is a useless comment.  It just says what anyone can see from the
> next line of code.  It would be better to say _why_ it is necessary to
> treat section symbols specially.
> 

Since now we create multiple symbols with the same name, I think
we need a new interface to lookup symbols with matching section.


H.J.
-----
2004-04-30  H.J. Lu  <hongjiu.lu@intel.com>

	* subsegs.c (section_symbol): Create a new section symbol if
	the existing one doesn't match.

--- gas/subsegs.c.same	2003-12-04 10:43:25.000000000 -0800
+++ gas/subsegs.c	2004-04-30 23:51:32.000000000 -0700
@@ -524,7 +524,9 @@ section_symbol (segT sec)
   else
     {
       s = symbol_find_base (sec->symbol->name, 0);
-      if (s == NULL)
+      /* We have to make sure it is the right symbol when we have
+	 multiple sections with the same section name.  */
+      if (s == NULL || S_GET_SEGMENT (s) != sec)
 	s = symbol_new (sec->symbol->name, sec, 0, &zero_address_frag);
       else
 	{

Re: PATCH: Multiple sections with same name don't work

[H. J. Lu]

On Sat, May 01, 2004 at 08:37:20AM -0700, H. J. Lu wrote:
> On Sun, May 02, 2004 at 12:14:39AM +0930, Alan Modra wrote:
> > On Sat, May 01, 2004 at 12:06:18AM -0700, H. J. Lu wrote:
> > > On Fri, Apr 30, 2004 at 10:50:08PM -0700, H. J. Lu wrote:
> > > > On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
> > > > > Alan Modra <amodra@bigpond.net.au> writes:
> > > > > > The real question is: Do we need multiple sections of the same name
> > > > > > in assembly files?  I don't think we do.
> > > > > 
> > > > > I need them in order to generate COMDAT sections compatible with the
> > > > > HPUX linker.  gcc might emit e.g.
> > > > > 
> > > > >      .section .text 
> > > > >      # non-COMDAT code  ...
> > > > > 
> > > > >      .section .text,"G",symbol_name,comdat
> > > > >      # code for symbol_name ...
> > 
> > Hmm, it wouldn't be much harder to use
> > 
> >      .section .text.symbol_name,"G",symbol_name,comdat
> >      # code for symbol_name ...
> > 
> > I fear HJ is going to be repeating the following a few more times.. 
> > 
> 
> I am ready for it.
> 
> > > This patch is not enough. Here is an updated one.
> > 
> > [snip]
> > > +  /* Don't reset it if it is already a BFD section symbol.  */
> > > +  if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
> > > +    s->bsym = bsym;
> 
> This patch is no longer needed for multiple section with the same
> name. The section_symbol patch is enough.
> 
> > 
> > This is a useless comment.  It just says what anyone can see from the
> > next line of code.  It would be better to say _why_ it is necessary to
> > treat section symbols specially.
> > 
> 
> Since now we create multiple symbols with the same name, I think
> we need a new interface to lookup symbols with matching section.
> 
> 

I was wrong on both. We don't need a new interface for symbol lookup.
Also we do need the symbol_set_bfdsym change.


H.J.
----
2004-05-01  H.J. Lu  <hongjiu.lu@intel.com>

	* subsegs.c (section_symbol): Create a new section symbol if
	the existing one doesn't match.

	* symbols.c (symbol_set_bfdsym): Don't reset BFD section symbol.

--- gas/subsegs.c.same	2003-12-04 10:43:25.000000000 -0800
+++ gas/subsegs.c	2004-05-01 09:13:31.000000000 -0700
@@ -524,7 +524,9 @@ section_symbol (segT sec)
   else
     {
       s = symbol_find_base (sec->symbol->name, 0);
-      if (s == NULL)
+      /* We have to make sure it is the right symbol when we have
+	 multiple sections with the same section name.  */
+      if (s == NULL || S_GET_SEGMENT (s) != sec)
 	s = symbol_new (sec->symbol->name, sec, 0, &zero_address_frag);
       else
 	{
--- gas/symbols.c.same	2004-05-01 07:55:53.000000000 -0700
+++ gas/symbols.c	2004-05-01 10:11:31.000000000 -0700
@@ -2260,7 +2260,15 @@ symbol_set_bfdsym (symbolS *s, asymbol *
 {
   if (LOCAL_SYMBOL_CHECK (s))
     s = local_symbol_convert ((struct local_symbol *) s);
-  s->bsym = bsym;
+  /* Usually, it is harmless to reset a symbol to a BFD section
+     symbol. For example, obj_elf_change_section sets the BFD symbol
+     of an old symbol with the newly created section symbol. But when
+     we have multiple sections with the same name, the newly created
+     section may have the same name as an old section. We check if the
+     old symbol has been already marked as a section symbol before
+     resetting it.  */
+  if ((s->bsym->flags & BSF_SECTION_SYM) == 0)
+    s->bsym = bsym;
 }
 
 #endif /* BFD_ASSEMBLER */

Re: PATCH: Multiple sections with same name don't work

[Zack Weinberg]

Alan Modra <amodra@bigpond.net.au> writes:

> On Sat, May 01, 2004 at 12:06:18AM -0700, H. J. Lu wrote:
>> On Fri, Apr 30, 2004 at 10:50:08PM -0700, H. J. Lu wrote:
>> > On Fri, Apr 30, 2004 at 10:12:01PM -0700, Zack Weinberg wrote:
>> > > Alan Modra <amodra@bigpond.net.au> writes:
>> > > > The real question is: Do we need multiple sections of the same name
>> > > > in assembly files?  I don't think we do.
>> > > 
>> > > I need them in order to generate COMDAT sections compatible with the
>> > > HPUX linker.  gcc might emit e.g.
>> > > 
>> > >      .section .text 
>> > >      # non-COMDAT code  ...
>> > > 
>> > >      .section .text,"G",symbol_name,comdat
>> > >      # code for symbol_name ...
>
> Hmm, it wouldn't be much harder to use
>
>      .section .text.symbol_name,"G",symbol_name,comdat
>      # code for symbol_name ...

That may not work.  Unfortunately, the HPUX linker's COMDAT-group
support is only partially documented, and subtly incompatible with the
standard ELF SHT_GROUP notion.  I am having to work things out by
reverse engineering what aCC does -- and it uses multiple sections
with the same name.

zw

Re: PATCH: Multiple sections with same name don't work

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi H.J.

> 2004-05-01  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* subsegs.c (section_symbol): Create a new section symbol if
> 	the existing one doesn't match.
> 
> 	* symbols.c (symbol_set_bfdsym): Don't reset BFD section
> 	symbol.

Approved and applied.

I also generated and applied a patch to add a testcase for this patch,
although I now see that you have posted a separate patch to do this.
Sorry for missing that.

I also took the opportunity to update the gas documentation for the
.section pseudo op to include the G and T flags.  The patch is
attached and this is the ChangeLog entry:

gas/ChangeLog
2004-05-11  Nick Clifton  <nickc@redhat.com>

	* doc/as.texinfo (Section): Document G and T flags to .section
	directive.  Document the extra arguments that the G flag
	requires.  Document the #tls flag.


Cheers
  Nick


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Document G and T flags to .section --]
[-- Type: text/x-patch, Size: 4699 bytes --]

Index: as.texinfo
===================================================================
RCS file: /cvs/src/src/gas/doc/as.texinfo,v
retrieving revision 1.99
retrieving revision 1.100
diff -c -3 -p -r1.99 -r1.100
*** as.texinfo	23 Apr 2004 04:50:53 -0000	1.99
--- as.texinfo	11 May 2004 15:53:47 -0000	1.100
*************** This is one of the ELF section stack man
*** 5211,5217 ****
  For ELF targets, the @code{.section} directive is used like this:
  
  @smallexample
! .section @var{name} [, "@var{flags}"[, @@@var{type}[, @@@var{entsize}]]]
  @end smallexample
  
  The optional @var{flags} argument is a quoted string which may contain any
--- 5211,5217 ----
  For ELF targets, the @code{.section} directive is used like this:
  
  @smallexample
! .section @var{name} [, "@var{flags}"[, @@@var{type}[,@var{flag_specific_arguments}]]
  @end smallexample
  
  The optional @var{flags} argument is a quoted string which may contain any
*************** section is executable
*** 5227,5232 ****
--- 5227,5236 ----
  section is mergeable
  @item S
  section contains zero terminated strings
+ @item G
+ section is a member of a section group
+ @item T
+ section is used for thread-local-storage
  @end table
  
  The optional @var{type} argument may contain one of the following constants:
*************** The optional @var{type} argument may con
*** 5235,5252 ****
  section contains data
  @item @@nobits
  section does not contain data (i.e., section only occupies space)
  @end table
  
  Note on targets where the @code{@@} character is the start of a comment (eg
  ARM) then another character is used instead.  For example the ARM port uses the
  @code{%} character.
  
! If @var{flags} contains @code{M} flag, @var{type} argument must be specified
! as well as @var{entsize} argument. Sections with @code{M} flag but not
! @code{S} flag must contain fixed size constants, each @var{entsize} octets
! long. Sections with both @code{M} and @code{S} must contain zero terminated
! strings where each character is @var{entsize} bytes long. The linker may remove
! duplicates within sections with the same name, same entity size and same flags. 
  
  If no flags are specified, the default flags depend upon the section name.  If
  the section name is not recognized, the default will be for the section to have
--- 5239,5288 ----
  section contains data
  @item @@nobits
  section does not contain data (i.e., section only occupies space)
+ @item @@note
+ section contains data which is used by things other than the program
  @end table
  
  Note on targets where the @code{@@} character is the start of a comment (eg
  ARM) then another character is used instead.  For example the ARM port uses the
  @code{%} character.
  
! If @var{flags} contains the @code{M} symbol then the @var{type} argument must
! be specified as well as an extra argument - @var{entsize} - like this:
! 
! @smallexample
! .section @var{name} , "@var{flags}"M, @@@var{type}, @var{entsize}
! @end smallexample
! 
! Sections with the @code{M} flag but not @code{S} flag must contain fixed size
! constants, each @var{entsize} octets long. Sections with both @code{M} and
! @code{S} must contain zero terminated strings where each character is
! @var{entsize} bytes long. The linker may remove duplicates within sections with
! the same name, same entity size and same flags.  @var{entsize} must be an
! absolute expression.
! 
! If @var{flags} contains the @code{G} symbol then the @var{type} argument must
! be present along with an additional field like this:
! 
! @smallexample
! .section @var{name} , "@var{flags}"G, @@@var{type}, @var{GroupName}[, @var{linkage}]
! @end smallexample
! 
! The @var{GroupName} field specifies the name of the section group to which this
! particular section belongs.  The optional linkage field can contain:
! @table @code
! @item comdat
! indicates that only one copy of this section should be retained
! @item .gnu.linkonce
! an alias for comdat
! @end table
! 
! Note - if both the @var{M} and @var{G} flags are present then the fields for
! the Merge flag should come first, like this:
! 
! @smallexample
! .section @var{name} , "@var{flags}"MG, @@@var{type}, @var{entsize}, @var{GroupName}[, @var{linkage}]
! @end smallexample
  
  If no flags are specified, the default flags depend upon the section name.  If
  the section name is not recognized, the default will be for the section to have
*************** section is allocatable
*** 5269,5274 ****
--- 5305,5312 ----
  section is writable
  @item #execinstr
  section is executable
+ @item #tls
+ section is used for thread local storage
  @end table
  
  This directive replaces the current section and subsection.  The replaced