RFC: Map GNU attributes section to PT_GNU_STACK segment

RFC: Map GNU attributes section to PT_GNU_STACK segment

[H.J. Lu]

We keep GNU attributes section in executable and shared library. Also
There is a PT_GNU_STACK segment. But only its segment type is used.
This patch maps GNU attributes section to PT_GNU_STACK segment and
makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU attributes
section is available to ELF loader.

Any comments?


H.J.
----
--- binutils/bfd/elf.c.attri	2007-08-14 12:49:05.000000000 -0700
+++ binutils/bfd/elf.c	2007-08-14 19:43:44.000000000 -0700
@@ -1083,7 +1083,7 @@ get_segment_type (unsigned int p_type)
     case PT_PHDR: pt = "PHDR"; break;
     case PT_TLS: pt = "TLS"; break;
     case PT_GNU_EH_FRAME: pt = "EH_FRAME"; break;
-    case PT_GNU_STACK: pt = "STACK"; break;
+    case PT_GNU_ATTRIBUTES: pt = "ATTRIBUTES"; break;
     case PT_GNU_RELRO: pt = "RELRO"; break;
     default: pt = NULL; break;
     }
@@ -2359,8 +2359,9 @@ bfd_section_from_phdr (bfd *abfd, Elf_In
       return _bfd_elf_make_section_from_phdr (abfd, hdr, index,
 					      "eh_frame_hdr");
 
-    case PT_GNU_STACK:
-      return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "stack");
+    case PT_GNU_ATTRIBUTES:
+      return _bfd_elf_make_section_from_phdr (abfd, hdr, index,
+					      "attributes");
 
     case PT_GNU_RELRO:
       return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "relro");
@@ -3304,7 +3305,8 @@ get_program_header_size (bfd *abfd, stru
 {
   size_t segs;
   asection *s;
-  const struct elf_backend_data *bed;
+  asection *attr = NULL;
+  const struct elf_backend_data *bed = get_elf_backend_data (abfd);
 
   /* Assume we will need exactly two PT_LOAD segments: one for text
      and one for data.  */
@@ -3339,14 +3341,25 @@ get_program_header_size (bfd *abfd, stru
       ++segs;
     }
 
-  if (elf_tdata (abfd)->stack_flags)
-    {
-      /* We need a PT_GNU_STACK segment.  */
-      ++segs;
-    }
-
   for (s = abfd->sections; s != NULL; s = s->next)
     {
+      if (elf_section_type (s) == bed->obj_attrs_section_type)
+	{
+	  BFD_ASSERT (attr == NULL);
+	  attr = s;
+
+	  /* PT_GNU_STACK and PT_GNU_ATTRIBUTES use the same segment.
+	     If there is no flags for PT_GNU_STACK, we set it to
+	     default. */
+	  if (! elf_tdata (abfd)->stack_flags)
+	    {
+	      if (bed->default_execstack)
+		elf_tdata (abfd)->stack_flags = PF_R | PF_W | PF_X;
+	      else
+		elf_tdata (abfd)->stack_flags = PF_R | PF_W;
+	    }
+	}
+
       if ((s->flags & SEC_LOAD) != 0
 	  && CONST_STRNEQ (s->name, ".note"))
 	{
@@ -3368,6 +3381,12 @@ get_program_header_size (bfd *abfd, stru
 	}
     }
 
+  if (elf_tdata (abfd)->stack_flags)
+    {
+      /* We need a PT_GNU_STACK segment.  */
+      ++segs;
+    }
+
   for (s = abfd->sections; s != NULL; s = s->next)
     {
       if (s->flags & SEC_THREAD_LOCAL)
@@ -3405,7 +3424,6 @@ get_program_header_size (bfd *abfd, stru
     }
 
   /* Let the backend count up any program headers it might need.  */
-  bed = get_elf_backend_data (abfd);
   if (bed->elf_backend_additional_program_headers)
     {
       int a;
@@ -3552,6 +3570,7 @@ _bfd_elf_map_sections_to_segments (bfd *
       asection *first_tls = NULL;
       asection *dynsec, *eh_frame_hdr;
       bfd_size_type amt;
+      asection *attr = NULL;
 
       /* Select the allocated sections, and sort them.  */
 
@@ -3562,6 +3581,12 @@ _bfd_elf_map_sections_to_segments (bfd *
       i = 0;
       for (s = abfd->sections; s != NULL; s = s->next)
 	{
+	  if (elf_section_type (s) == bed->obj_attrs_section_type)
+	    {
+	      BFD_ASSERT (attr == NULL);
+	      attr = s;
+	    }
+
 	  if ((s->flags & SEC_ALLOC) != 0)
 	    {
 	      sections[i] = s;
@@ -3949,6 +3974,15 @@ _bfd_elf_map_sections_to_segments (bfd *
 	  m->p_flags = elf_tdata (abfd)->stack_flags;
 	  m->p_flags_valid = 1;
 
+	  if (attr)
+	    {
+	      /* PT_GNU_ATTRIBUTES uses the same segment as
+		 PT_GNU_STACK. If there is attribute asection,
+		 add it for PT_GNU_ATTRIBUTES segment.  */
+	      m->count = 1;
+	      m->sections[0] = attr;
+	    } 
+
 	  *pm = m;
 	  pm = &m->next;
 	}
@@ -5178,31 +5212,34 @@ rewrite_elf_program_header (bfd *ibfd, b
        2. It is an allocated segment,
        3. There is an output section associated with it,
        4. The section has not already been allocated to a previous segment.
-       5. PT_GNU_STACK segments do not include any sections.
+       5. PT_GNU_STACK and PT_GNU_ATTRIBUTES use thes same segment,
+	  which contains attribute section.
        6. PT_TLS segment includes only SHF_TLS sections.
        7. SHF_TLS sections are only in PT_TLS or PT_LOAD segments.
        8. PT_DYNAMIC should not contain empty sections at the beginning
 	  (with the possible exception of .dynamic).  */
 #define IS_SECTION_IN_INPUT_SEGMENT(section, segment, bed)		\
-  ((((segment->p_paddr							\
-      ? IS_CONTAINED_BY_LMA (section, segment, segment->p_paddr)	\
-      : IS_CONTAINED_BY_VMA (section, segment))				\
-     && (section->flags & SEC_ALLOC) != 0)				\
-    || IS_COREFILE_NOTE (segment, section))				\
-   && segment->p_type != PT_GNU_STACK					\
-   && (segment->p_type != PT_TLS					\
-       || (section->flags & SEC_THREAD_LOCAL))				\
-   && (segment->p_type == PT_LOAD					\
-       || segment->p_type == PT_TLS					\
-       || (section->flags & SEC_THREAD_LOCAL) == 0)			\
-   && (segment->p_type != PT_DYNAMIC					\
-       || SECTION_SIZE (section, segment) > 0				\
-       || (segment->p_paddr						\
-	   ? segment->p_paddr != section->lma				\
-	   : segment->p_vaddr != section->vma)				\
-       || (strcmp (bfd_get_section_name (ibfd, section), ".dynamic")	\
-	   == 0))							\
-   && ! section->segment_mark)
+  ((segment->p_type == PT_GNU_ATTRIBUTES				\
+    && elf_section_type (section) == bed->obj_attrs_section_type)	\
+   || ((((segment->p_paddr						\
+	  ? IS_CONTAINED_BY_LMA (section, segment, segment->p_paddr)	\
+	  : IS_CONTAINED_BY_VMA (section, segment))			\
+	 && (section->flags & SEC_ALLOC) != 0)				\
+	|| IS_COREFILE_NOTE (segment, section))				\
+       && segment->p_type != PT_GNU_STACK				\
+       && (segment->p_type != PT_TLS					\
+	   || (section->flags & SEC_THREAD_LOCAL))			\
+       && (segment->p_type == PT_LOAD					\
+	   || segment->p_type == PT_TLS					\
+	   || (section->flags & SEC_THREAD_LOCAL) == 0)			\
+       && (segment->p_type != PT_DYNAMIC				\
+	   || SECTION_SIZE (section, segment) > 0			\
+	   || (segment->p_paddr						\
+	       ? segment->p_paddr != section->lma			\
+	       : segment->p_vaddr != section->vma)			\
+	   || (strcmp (bfd_get_section_name (ibfd, section),		\
+		       ".dynamic") == 0))				\
+       && ! section->segment_mark))
 
 /* If the output section of a section in the input segment is NULL,
    it is removed from the corresponding output segment.   */
--- binutils/binutils/readelf.c.attri	2007-08-14 12:49:05.000000000 -0700
+++ binutils/binutils/readelf.c	2007-08-14 19:44:22.000000000 -0700
@@ -2470,7 +2470,8 @@ get_segment_type (unsigned long p_type)
 
     case PT_GNU_EH_FRAME:
 			return "GNU_EH_FRAME";
-    case PT_GNU_STACK:	return "GNU_STACK";
+    case PT_GNU_ATTRIBUTES:
+			return "GNU_ATTRIBUTES";
     case PT_GNU_RELRO:  return "GNU_RELRO";
 
     default:
--- binutils/include/elf/common.h.attri	2007-08-14 12:49:05.000000000 -0700
+++ binutils/include/elf/common.h	2007-08-14 16:45:19.000000000 -0700
@@ -308,6 +308,7 @@
 #define PT_GNU_EH_FRAME	(PT_LOOS + 0x474e550) /* Frame unwind information */
 #define PT_SUNW_EH_FRAME PT_GNU_EH_FRAME      /* Solaris uses the same value */
 #define PT_GNU_STACK	(PT_LOOS + 0x474e551) /* Stack flags */
+#define PT_GNU_ATTRIBUTES PT_GNU_STACK	      /* Attribute flags */
 #define PT_GNU_RELRO	(PT_LOOS + 0x474e552) /* Read-only after relocation */
 #define PT_GNU_SHR	(PT_LOOS + 0x474e554) /* Sharable segment */
 

Re: RFC: Map GNU attributes section to PT_GNU_STACK segment

[Nick Clifton]

Hi H.J.

> We keep GNU attributes section in executable and shared library. Also
> There is a PT_GNU_STACK segment. But only its segment type is used.
> This patch maps GNU attributes section to PT_GNU_STACK segment and
> makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU attributes
> section is available to ELF loader.

Why do you want to do this ?  In particular why do you want to overload the 
PT_GNU_STACK segment ?  Why not create a new PT_GNU_ATTR segment ?  Is space in 
the header the only reason ?

It seems to me that overloading the PT_GNU_STACK segment in the way you propose 
is prone to confusing the user, and I think that we ought to try to avoid this.

On the other hand, if you are trying to tidy up the program headers then maybe 
it would be cleaner to have a new name (eg PT_GNU_STUFF) and then define an 
*extendable* scheme for putting loader-accessible information into this 
segment.  Using this scheme you can then define a replacement for the current 
PT_GNU_STACK segment and a home for the GNU attributes section.  Ideally this 
new segment would be backwards compatible with the current PT_GNU_STACK segment 
(same type, same flags) so that older loaders can still use it.

Cheers
   Nick

Re: RFC: Map GNU attributes section to PT_GNU_STACK segment

[H.J. Lu]

On Wed, Aug 15, 2007 at 05:07:37PM +0100, Nick Clifton wrote:
> Hi H.J.
> 
> >We keep GNU attributes section in executable and shared library. Also
> >There is a PT_GNU_STACK segment. But only its segment type is used.
> >This patch maps GNU attributes section to PT_GNU_STACK segment and
> >makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU attributes
> >section is available to ELF loader.
> 
> Why do you want to do this ?  In particular why do you want to overload the 
> PT_GNU_STACK segment ?  Why not create a new PT_GNU_ATTR segment ?  Is 
> space in the header the only reason ?
> 
> It seems to me that overloading the PT_GNU_STACK segment in the way you 
> propose is prone to confusing the user, and I think that we ought to try to 
> avoid this.

The current usage of the PT_GNU_STACK segment is the flags field
only.  All other fields are ignored.  The new segment ignores the
flags field.  Overloading the PT_GNU_STACK segment seems a good
idea to me since it is totally backward and forward compatible.

> 
> On the other hand, if you are trying to tidy up the program headers then 
> maybe it would be cleaner to have a new name (eg PT_GNU_STUFF) and then 
> define an *extendable* scheme for putting loader-accessible information 
> into this segment.  Using this scheme you can then define a replacement for 
> the current PT_GNU_STACK segment and a home for the GNU attributes section. 
> Ideally this new segment would be backwards compatible with the current 
> PT_GNU_STACK segment (same type, same flags) so that older loaders can 
> still use it.

That is what my proposal does. The only difference is I call the
new segment PT_GNU_ATTRIBUTES.  I don't mind we use a differrent
name at all.  The loader-accessible information belongs to the GNU
attributes section and it is extendable.


H.J.

Re: RFC: Map GNU attributes section to PT_GNU_STACK segment

[Nick Clifton]

Hi H.J.

> The current usage of the PT_GNU_STACK segment is the flags field
> only.  All other fields are ignored.  The new segment ignores the
> flags field.  Overloading the PT_GNU_STACK segment seems a good
> idea to me since it is totally backward and forward compatible.

I agree that it is forward and backward compatible.  I am just worried that the 
name of the segment, if set to PT_GNU_ATTRIBUTES or left as PT_GNU_STACK, would 
be confusing.  I think that we ought to have a more generic type of name and 
then have a well defined scheme for storing information in this segment.

> That is what my proposal does. The only difference is I call the
> new segment PT_GNU_ATTRIBUTES.  I don't mind we use a differrent
> name at all.  The loader-accessible information belongs to the GNU
> attributes section and it is extendable.

True, so maybe we ought to have a GNU_STACK attribute and use that.  For 
backwards compatibility we can still set the flags of the segment 
appropriately, but that would only be for backwards compatibility.  Any future 
uses of the segment would not make use of the flags to specify any information.

Cheers
   Nick

PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[H.J. Lu]

On Wed, Aug 15, 2007 at 05:39:48PM +0100, Nick Clifton wrote:
> Hi H.J.
> 
> >The current usage of the PT_GNU_STACK segment is the flags field
> >only.  All other fields are ignored.  The new segment ignores the
> >flags field.  Overloading the PT_GNU_STACK segment seems a good
> >idea to me since it is totally backward and forward compatible.
> 
> I agree that it is forward and backward compatible.  I am just worried that 
> the name of the segment, if set to PT_GNU_ATTRIBUTES or left as 
> PT_GNU_STACK, would be confusing.  I think that we ought to have a more 
> generic type of name and then have a well defined scheme for storing 
> information in this segment.

I change it to PT_GNU_ATTR.

> 
> >That is what my proposal does. The only difference is I call the
> >new segment PT_GNU_ATTRIBUTES.  I don't mind we use a differrent
> >name at all.  The loader-accessible information belongs to the GNU
> >attributes section and it is extendable.
> 
> True, so maybe we ought to have a GNU_STACK attribute and use that.  For 
> backwards compatibility we can still set the flags of the segment 
> appropriately, but that would only be for backwards compatibility.  Any 
> future uses of the segment would not make use of the flags to specify any 
> information.
> 
> 

I am not sure if it is worth the change since a special note section,
.note.GNU-stack, is used to specify the stack flags. Moving it to
the .gnu.attributes section will require changes in gcc, binutils
and applications. We have to keep .note.GNU-stack because of it. We
can add new ones to .gnu.attributes, but should leave the stack flags
alone.

Thanks.


H.J.
---
bfd/

2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>

	* elf.c (get_segment_type): Change PT_GNU_STACK to PT_GNU_ATTR.
	(bfd_section_from_phdr): Likewise.
	(get_program_header_size): Likewise. Add a PT_GNU_ATTR segment
	if there is an attribute section.
	(_bfd_elf_map_sections_to_segments): Likewise.
	(IS_SECTION_IN_INPUT_SEGMENT): Likewise.

binutils/

2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>

	* readelf.c (get_segment_type): Change PT_GNU_STACK to
	PT_GNU_ATTR.

include/elf/

2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>

	* common.h (PT_GNU_STACK): Renamed to ...
	(PT_GNU_ATTR): This.
	(PT_GNU_STACK): New.  Make an alias of PT_GNU_ATTR.

--- binutils/bfd/elf.c.attri	2007-08-14 08:41:55.000000000 -0700
+++ binutils/bfd/elf.c	2007-08-15 10:04:21.000000000 -0700
@@ -1083,7 +1083,7 @@ get_segment_type (unsigned int p_type)
     case PT_PHDR: pt = "PHDR"; break;
     case PT_TLS: pt = "TLS"; break;
     case PT_GNU_EH_FRAME: pt = "EH_FRAME"; break;
-    case PT_GNU_STACK: pt = "STACK"; break;
+    case PT_GNU_ATTR: pt = "ATTR"; break;
     case PT_GNU_RELRO: pt = "RELRO"; break;
     default: pt = NULL; break;
     }
@@ -2355,8 +2355,8 @@ bfd_section_from_phdr (bfd *abfd, Elf_In
       return _bfd_elf_make_section_from_phdr (abfd, hdr, index,
 					      "eh_frame_hdr");
 
-    case PT_GNU_STACK:
-      return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "stack");
+    case PT_GNU_ATTR:
+      return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "attr");
 
     case PT_GNU_RELRO:
       return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "relro");
@@ -3300,7 +3300,8 @@ get_program_header_size (bfd *abfd, stru
 {
   size_t segs;
   asection *s;
-  const struct elf_backend_data *bed;
+  asection *attr = NULL;
+  const struct elf_backend_data *bed = get_elf_backend_data (abfd);
 
   /* Assume we will need exactly two PT_LOAD segments: one for text
      and one for data.  */
@@ -3335,14 +3336,26 @@ get_program_header_size (bfd *abfd, stru
       ++segs;
     }
 
-  if (elf_tdata (abfd)->stack_flags)
-    {
-      /* We need a PT_GNU_STACK segment.  */
-      ++segs;
-    }
-
   for (s = abfd->sections; s != NULL; s = s->next)
     {
+      if (elf_section_type (s) == bed->obj_attrs_section_type)
+	{
+	  BFD_ASSERT (attr == NULL);
+	  attr = s;
+
+	  /* elf_tdata (abfd)->stack_flags is checked for the
+	     PT_GNU_ATTR segment.  If there is an attribute
+	     section, we make sure that stack_flags isn't zero so
+	     that the PT_GNU_ATTR segment will be created.  */
+	  if (! elf_tdata (abfd)->stack_flags)
+	    {
+	      if (bed->default_execstack)
+		elf_tdata (abfd)->stack_flags = PF_R | PF_W | PF_X;
+	      else
+		elf_tdata (abfd)->stack_flags = PF_R | PF_W;
+	    }
+	}
+
       if ((s->flags & SEC_LOAD) != 0
 	  && CONST_STRNEQ (s->name, ".note"))
 	{
@@ -3364,6 +3377,12 @@ get_program_header_size (bfd *abfd, stru
 	}
     }
 
+  if (elf_tdata (abfd)->stack_flags)
+    {
+      /* We need a PT_GNU_ATTR segment.  */
+      ++segs;
+    }
+
   for (s = abfd->sections; s != NULL; s = s->next)
     {
       if (s->flags & SEC_THREAD_LOCAL)
@@ -3375,7 +3394,6 @@ get_program_header_size (bfd *abfd, stru
     }
 
   /* Let the backend count up any program headers it might need.  */
-  bed = get_elf_backend_data (abfd);
   if (bed->elf_backend_additional_program_headers)
     {
       int a;
@@ -3520,6 +3538,7 @@ _bfd_elf_map_sections_to_segments (bfd *
       asection *first_tls = NULL;
       asection *dynsec, *eh_frame_hdr;
       bfd_size_type amt;
+      asection *attr = NULL;
 
       /* Select the allocated sections, and sort them.  */
 
@@ -3530,6 +3549,12 @@ _bfd_elf_map_sections_to_segments (bfd *
       i = 0;
       for (s = abfd->sections; s != NULL; s = s->next)
 	{
+	  if (elf_section_type (s) == bed->obj_attrs_section_type)
+	    {
+	      BFD_ASSERT (attr == NULL);
+	      attr = s;
+	    }
+
 	  if ((s->flags & SEC_ALLOC) != 0)
 	    {
 	      sections[i] = s;
@@ -3843,10 +3868,17 @@ _bfd_elf_map_sections_to_segments (bfd *
 	  if (m == NULL)
 	    goto error_return;
 	  m->next = NULL;
-	  m->p_type = PT_GNU_STACK;
+	  m->p_type = PT_GNU_ATTR;
 	  m->p_flags = elf_tdata (abfd)->stack_flags;
 	  m->p_flags_valid = 1;
 
+	  if (attr)
+	    {
+	      /* Add the attribute section if needed.  */
+	      m->count = 1;
+	      m->sections[0] = attr;
+	    } 
+
 	  *pm = m;
 	  pm = &m->next;
 	}
@@ -5033,31 +5065,33 @@ rewrite_elf_program_header (bfd *ibfd, b
        2. It is an allocated segment,
        3. There is an output section associated with it,
        4. The section has not already been allocated to a previous segment.
-       5. PT_GNU_STACK segments do not include any sections.
+       5. PT_GNU_ATTR only contains attribute section.
        6. PT_TLS segment includes only SHF_TLS sections.
        7. SHF_TLS sections are only in PT_TLS or PT_LOAD segments.
        8. PT_DYNAMIC should not contain empty sections at the beginning
 	  (with the possible exception of .dynamic).  */
 #define IS_SECTION_IN_INPUT_SEGMENT(section, segment, bed)		\
-  ((((segment->p_paddr							\
-      ? IS_CONTAINED_BY_LMA (section, segment, segment->p_paddr)	\
-      : IS_CONTAINED_BY_VMA (section, segment))				\
-     && (section->flags & SEC_ALLOC) != 0)				\
-    || IS_COREFILE_NOTE (segment, section))				\
-   && segment->p_type != PT_GNU_STACK					\
-   && (segment->p_type != PT_TLS					\
-       || (section->flags & SEC_THREAD_LOCAL))				\
-   && (segment->p_type == PT_LOAD					\
-       || segment->p_type == PT_TLS					\
-       || (section->flags & SEC_THREAD_LOCAL) == 0)			\
-   && (segment->p_type != PT_DYNAMIC					\
-       || SECTION_SIZE (section, segment) > 0				\
-       || (segment->p_paddr						\
-	   ? segment->p_paddr != section->lma				\
-	   : segment->p_vaddr != section->vma)				\
-       || (strcmp (bfd_get_section_name (ibfd, section), ".dynamic")	\
-	   == 0))							\
-   && ! section->segment_mark)
+  ((segment->p_type == PT_GNU_ATTR					\
+    && elf_section_type (section) == bed->obj_attrs_section_type)	\
+   || ((((segment->p_paddr						\
+	  ? IS_CONTAINED_BY_LMA (section, segment, segment->p_paddr)	\
+	  : IS_CONTAINED_BY_VMA (section, segment))			\
+	 && (section->flags & SEC_ALLOC) != 0)				\
+	|| IS_COREFILE_NOTE (segment, section))				\
+       && segment->p_type != PT_GNU_ATTR				\
+       && (segment->p_type != PT_TLS					\
+	   || (section->flags & SEC_THREAD_LOCAL))			\
+       && (segment->p_type == PT_LOAD					\
+	   || segment->p_type == PT_TLS					\
+	   || (section->flags & SEC_THREAD_LOCAL) == 0)			\
+       && (segment->p_type != PT_DYNAMIC				\
+	   || SECTION_SIZE (section, segment) > 0			\
+	   || (segment->p_paddr						\
+	       ? segment->p_paddr != section->lma			\
+	       : segment->p_vaddr != section->vma)			\
+	   || (strcmp (bfd_get_section_name (ibfd, section),		\
+		       ".dynamic") == 0))				\
+       && ! section->segment_mark))
 
 /* If the output section of a section in the input segment is NULL,
    it is removed from the corresponding output segment.   */
--- binutils/binutils/readelf.c.attri	2007-07-27 12:52:07.000000000 -0700
+++ binutils/binutils/readelf.c	2007-08-15 09:55:17.000000000 -0700
@@ -2467,7 +2467,7 @@ get_segment_type (unsigned long p_type)
 
     case PT_GNU_EH_FRAME:
 			return "GNU_EH_FRAME";
-    case PT_GNU_STACK:	return "GNU_STACK";
+    case PT_GNU_ATTR:	return "GNU_ATTR";
     case PT_GNU_RELRO:  return "GNU_RELRO";
 
     default:
--- binutils/include/elf/common.h.attri	2007-07-24 15:03:52.000000000 -0700
+++ binutils/include/elf/common.h	2007-08-15 09:49:15.000000000 -0700
@@ -307,7 +307,8 @@
 
 #define PT_GNU_EH_FRAME	(PT_LOOS + 0x474e550) /* Frame unwind information */
 #define PT_SUNW_EH_FRAME PT_GNU_EH_FRAME      /* Solaris uses the same value */
-#define PT_GNU_STACK	(PT_LOOS + 0x474e551) /* Stack flags */
+#define PT_GNU_ATTR	(PT_LOOS + 0x474e551) /* Attribute info */
+#define PT_GNU_STACK	PT_GNU_ATTR	      /* Stack flags */
 #define PT_GNU_RELRO	(PT_LOOS + 0x474e552) /* Read-only after relocation */
 
 /* Program segment permissions, in program header p_flags field.  */

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Nick Clifton]

Hi H.J.

> I am not sure if it is worth the change since a special note section,
> .note.GNU-stack, is used to specify the stack flags. Moving it to
> the .gnu.attributes section will require changes in gcc, binutils
> and applications. We have to keep .note.GNU-stack because of it. We
> can add new ones to .gnu.attributes, but should leave the stack flags
> alone.

Good point - OK, lets stick with what you have.

> bfd/
> 2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* elf.c (get_segment_type): Change PT_GNU_STACK to PT_GNU_ATTR.
> 	(bfd_section_from_phdr): Likewise.
> 	(get_program_header_size): Likewise. Add a PT_GNU_ATTR segment
> 	if there is an attribute section.
> 	(_bfd_elf_map_sections_to_segments): Likewise.
> 	(IS_SECTION_IN_INPUT_SEGMENT): Likewise.
> 
> binutils/
> 2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* readelf.c (get_segment_type): Change PT_GNU_STACK to
> 	PT_GNU_ATTR.
> 
> include/elf/
> 2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* common.h (PT_GNU_STACK): Renamed to ...
> 	(PT_GNU_ATTR): This.
> 	(PT_GNU_STACK): New.  Make an alias of PT_GNU_ATTR.

Approved - please apply.

Cheers
   Nick

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Daniel Jacobowitz]

On Wed, Aug 15, 2007 at 10:07:12AM -0700, H.J. Lu wrote:
> 2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* elf.c (get_segment_type): Change PT_GNU_STACK to PT_GNU_ATTR.
> 	(bfd_section_from_phdr): Likewise.
> 	(get_program_header_size): Likewise. Add a PT_GNU_ATTR segment
> 	if there is an attribute section.
> 	(_bfd_elf_map_sections_to_segments): Likewise.
> 	(IS_SECTION_IN_INPUT_SEGMENT): Likewise.

How is this going to work?  .gnu.attributes is not SEC_ALLOC.  Also,
I'm not sure we can make .ARM.attributes SEC_ALLOC without breaking
the ARM EABI.

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[H.J. Lu]

On Thu, Aug 16, 2007 at 07:26:36AM -0400, Daniel Jacobowitz wrote:
> On Wed, Aug 15, 2007 at 10:07:12AM -0700, H.J. Lu wrote:
> > 2007-08-15  H.J. Lu  <hongjiu.lu@intel.com>
> > 
> > 	* elf.c (get_segment_type): Change PT_GNU_STACK to PT_GNU_ATTR.
> > 	(bfd_section_from_phdr): Likewise.
> > 	(get_program_header_size): Likewise. Add a PT_GNU_ATTR segment
> > 	if there is an attribute section.
> > 	(_bfd_elf_map_sections_to_segments): Likewise.
> > 	(IS_SECTION_IN_INPUT_SEGMENT): Likewise.
> 
> How is this going to work?  .gnu.attributes is not SEC_ALLOC.  Also,
> I'm not sure we can make .ARM.attributes SEC_ALLOC without breaking
> the ARM EABI.
> 

Why does the attribute section have to be SEC_ALLOC?  That is what
I got:

[hjl@gnu-6 attr-1]$ ./readelf -lS x
There are 6 section headers, starting at offset 0x8064:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00008000 008000 000004 00  AX  0   0  4
  [ 2] .ARM.attributes   ARM_ATTRIBUTES  00000000 008004 00002c 00      0   0  1
  [ 3] .shstrtab         STRTAB          00000000 008030 000031 00      0   0  1
  [ 4] .symtab           SYMTAB          00000000 008154 000110 10      5   6  4
  [ 5] .strtab           STRTAB          00000000 008264 000097 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x8000
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x008000 0x00008000 0x00008000 0x00004 0x00004 R E 0x8000
  GNU_ATTR       0x008004 0x00000000 0x00000000 0x0002c 0x00000 RW  0x1

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .ARM.attributes
[hjl@gnu-6 attr-1]$

Run-time loader can access the attribute section by checking offset
and filesize without making it SEC_ALLOC.


H.J.

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Daniel Jacobowitz]

On Thu, Aug 16, 2007 at 05:54:55AM -0700, H.J. Lu wrote:
>   GNU_ATTR       0x008004 0x00000000 0x00000000 0x0002c 0x00000 RW  0x1
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00     .text
>    01     .ARM.attributes
> [hjl@gnu-6 attr-1]$
> 
> Run-time loader can access the attribute section by checking offset
> and filesize without making it SEC_ALLOC.

Because you now have a non-allocated section that you want the runtime
loader to look at.  There's no guarantee that it is mapped in memory
anywhere after mapping the PT_LOAD segments.  Forcing the runtime
loader to make an extra mmap to get at the attributes basically
ensures that glibc's loader won't do so - that's at least one extra
syscall for every loaded object.

How are you planning to use this in the loader, and have you discussed
it with the glibc maintainers at all?

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[H.J. Lu]

On Thu, Aug 16, 2007 at 09:06:57AM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 05:54:55AM -0700, H.J. Lu wrote:
> >   GNU_ATTR       0x008004 0x00000000 0x00000000 0x0002c 0x00000 RW  0x1
> > 
> >  Section to Segment mapping:
> >   Segment Sections...
> >    00     .text
> >    01     .ARM.attributes
> > [hjl@gnu-6 attr-1]$
> > 
> > Run-time loader can access the attribute section by checking offset
> > and filesize without making it SEC_ALLOC.
> 
> Because you now have a non-allocated section that you want the runtime
> loader to look at.  There's no guarantee that it is mapped in memory
> anywhere after mapping the PT_LOAD segments.  Forcing the runtime
> loader to make an extra mmap to get at the attributes basically
> ensures that glibc's loader won't do so - that's at least one extra
> syscall for every loaded object.

Not if the size of GNU_ATTR is 0.

> 
> How are you planning to use this in the loader, and have you discussed
> it with the glibc maintainers at all?
> 

My patch only makes the existing info available to run-time loader.
It is up to run-time loader to decide if it wants to look at it.
At the moment, I don't have an attribute the run-time loader has
to check. But things may change in the future. 

Assuming we want to make the attribute section SHF_ALLOC, what kind
of problem will it cause for ARM EABI?


H.J.

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Daniel Jacobowitz]

On Thu, Aug 16, 2007 at 06:20:50AM -0700, H.J. Lu wrote:
> Not if the size of GNU_ATTR is 0.

It is unlikely to be in the future.  I expect we will use this
mechanism for many platforms.  We already do on ARM, MIPS, and Power.

> > How are you planning to use this in the loader, and have you discussed
> > it with the glibc maintainers at all?
> 
> My patch only makes the existing info available to run-time loader.
> It is up to run-time loader to decide if it wants to look at it.
> At the moment, I don't have an attribute the run-time loader has
> to check. But things may change in the future. 

If the run time loader wants to check, your mechanism will not be
suitable.  There's no chance that glibc will do an extra mmap or
seek/read to get at this information.

I don't think this patch is a good idea.  I would prefer to back it
out until there is a clear use case and support from at least one
consumer.

> Assuming we want to make the attribute section SHF_ALLOC, what kind
> of problem will it cause for ARM EABI?

Apparently none; the EABI does not specify that the section is
non-ALLOC.

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[H.J. Lu]

On Thu, Aug 16, 2007 at 09:43:10AM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 06:20:50AM -0700, H.J. Lu wrote:
> > Not if the size of GNU_ATTR is 0.
> 
> It is unlikely to be in the future.  I expect we will use this
> mechanism for many platforms.  We already do on ARM, MIPS, and Power.
> 
> > > How are you planning to use this in the loader, and have you discussed
> > > it with the glibc maintainers at all?
> > 
> > My patch only makes the existing info available to run-time loader.
> > It is up to run-time loader to decide if it wants to look at it.
> > At the moment, I don't have an attribute the run-time loader has
> > to check. But things may change in the future. 
> 
> If the run time loader wants to check, your mechanism will not be
> suitable.  There's no chance that glibc will do an extra mmap or
> seek/read to get at this information.
> 
> I don't think this patch is a good idea.  I would prefer to back it
> out until there is a clear use case and support from at least one
> consumer.

I have got a request to mark a binary for a totally different ABI than
the normal one. They wanted to use ELF header to mark the ABI. But the
bits in ELF header are very limited. The attribute section is
perfect for this.

> 
> > Assuming we want to make the attribute section SHF_ALLOC, what kind
> > of problem will it cause for ARM EABI?
> 
> Apparently none; the EABI does not specify that the section is
> non-ALLOC.
> 

Then, can we make the attribute section SHF_ALLOC?


H.J.

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Daniel Jacobowitz]

On Thu, Aug 16, 2007 at 06:53:58AM -0700, H.J. Lu wrote:
> On Thu, Aug 16, 2007 at 09:43:10AM -0400, Daniel Jacobowitz wrote:
> > I don't think this patch is a good idea.  I would prefer to back it
> > out until there is a clear use case and support from at least one
> > consumer.
> 
> I have got a request to mark a binary for a totally different ABI than
> the normal one. They wanted to use ELF header to mark the ABI. But the
> bits in ELF header are very limited. The attribute section is
> perfect for this.

I stand by my request.  Please at least talk to Jakub about this
before you go changing program headers.

> > > Assuming we want to make the attribute section SHF_ALLOC, what kind
> > > of problem will it cause for ARM EABI?
> > 
> > Apparently none; the EABI does not specify that the section is
> > non-ALLOC.
> > 
> 
> Then, can we make the attribute section SHF_ALLOC?

We may need a separate section for runtime useful notes.  I have not
thought about it, but someone needs to.  The attributes section can
get pretty bulky, e.g. 57 bytes for the default options of the ARM
compiler on an empty file.  We've been discussing internally an
attribute that would take a pathname, too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Map GNU attributes section to PT_GNU_STACK segment

[Mike Frysinger]

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

On Wednesday 15 August 2007, H.J. Lu wrote:
> On Wed, Aug 15, 2007 at 05:07:37PM +0100, Nick Clifton wrote:
> > Hi H.J.
> >
> > >We keep GNU attributes section in executable and shared library. Also
> > >There is a PT_GNU_STACK segment. But only its segment type is used.
> > >This patch maps GNU attributes section to PT_GNU_STACK segment and
> > >makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU attributes
> > >section is available to ELF loader.
> >
> > Why do you want to do this ?  In particular why do you want to overload
> > the PT_GNU_STACK segment ?  Why not create a new PT_GNU_ATTR segment ? 
> > Is space in the header the only reason ?
> >
> > It seems to me that overloading the PT_GNU_STACK segment in the way you
> > propose is prone to confusing the user, and I think that we ought to try
> > to avoid this.
>
> The current usage of the PT_GNU_STACK segment is the flags field
> only.  All other fields are ignored.  The new segment ignores the
> flags field.  Overloading the PT_GNU_STACK segment seems a good
> idea to me since it is totally backward and forward compatible.

this is not correct ... on Blackfin, we use the other attributes of 
PT_GNU_STACK (like the memsize field) to control the stack size (since 
Blackfin is a no-mmu)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: RFC: Map GNU attributes section to PT_GNU_STACK segment

[Mike Frysinger]

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

On Wednesday 15 August 2007, H.J. Lu wrote:
> On Wed, Aug 15, 2007 at 05:07:37PM +0100, Nick Clifton wrote:
> > Hi H.J.
> >
> > >We keep GNU attributes section in executable and shared library. Also
> > >There is a PT_GNU_STACK segment. But only its segment type is used.
> > >This patch maps GNU attributes section to PT_GNU_STACK segment and
> > >makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU attributes
> > >section is available to ELF loader.
> >
> > Why do you want to do this ?  In particular why do you want to overload
> > the PT_GNU_STACK segment ?  Why not create a new PT_GNU_ATTR segment ? 
> > Is space in the header the only reason ?
> >
> > It seems to me that overloading the PT_GNU_STACK segment in the way you
> > propose is prone to confusing the user, and I think that we ought to try
> > to avoid this.
>
> The current usage of the PT_GNU_STACK segment is the flags field
> only.  All other fields are ignored.  The new segment ignores the
> flags field.  Overloading the PT_GNU_STACK segment seems a good
> idea to me since it is totally backward and forward compatible.

this is not correct ... on Blackfin, we use the other attributes of 
PT_GNU_STACK (like the memsize field) to control the stack size (since 
Blackfin is a no-mmu)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: RFC: Map GNU attributes section to PT_GNU_STACK segment

[Mike Frysinger]

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

On Thursday 16 August 2007, Mike Frysinger wrote:
> On Wednesday 15 August 2007, H.J. Lu wrote:
> > On Wed, Aug 15, 2007 at 05:07:37PM +0100, Nick Clifton wrote:
> > > Hi H.J.
> > >
> > > >We keep GNU attributes section in executable and shared library. Also
> > > >There is a PT_GNU_STACK segment. But only its segment type is used.
> > > >This patch maps GNU attributes section to PT_GNU_STACK segment and
> > > >makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU
> > > > attributes section is available to ELF loader.
> > >
> > > Why do you want to do this ?  In particular why do you want to overload
> > > the PT_GNU_STACK segment ?  Why not create a new PT_GNU_ATTR segment ?
> > > Is space in the header the only reason ?
> > >
> > > It seems to me that overloading the PT_GNU_STACK segment in the way you
> > > propose is prone to confusing the user, and I think that we ought to
> > > try to avoid this.
> >
> > The current usage of the PT_GNU_STACK segment is the flags field
> > only.  All other fields are ignored.  The new segment ignores the
> > flags field.  Overloading the PT_GNU_STACK segment seems a good
> > idea to me since it is totally backward and forward compatible.
>
> this is not correct ... on Blackfin, we use the other attributes of
> PT_GNU_STACK (like the memsize field) to control the stack size (since
> Blackfin is a no-mmu)

to be a little more precise ... all Linux ports which support FDPIC ELF 
utilize the memsize field to set the stack size of the application, so this 
isnt Blackfin-specific
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: RFC: Map GNU attributes section to PT_GNU_STACK segment

[Mike Frysinger]

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

On Thursday 16 August 2007, Mike Frysinger wrote:
> On Wednesday 15 August 2007, H.J. Lu wrote:
> > On Wed, Aug 15, 2007 at 05:07:37PM +0100, Nick Clifton wrote:
> > > Hi H.J.
> > >
> > > >We keep GNU attributes section in executable and shared library. Also
> > > >There is a PT_GNU_STACK segment. But only its segment type is used.
> > > >This patch maps GNU attributes section to PT_GNU_STACK segment and
> > > >makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU
> > > > attributes section is available to ELF loader.
> > >
> > > Why do you want to do this ?  In particular why do you want to overload
> > > the PT_GNU_STACK segment ?  Why not create a new PT_GNU_ATTR segment ?
> > > Is space in the header the only reason ?
> > >
> > > It seems to me that overloading the PT_GNU_STACK segment in the way you
> > > propose is prone to confusing the user, and I think that we ought to
> > > try to avoid this.
> >
> > The current usage of the PT_GNU_STACK segment is the flags field
> > only.  All other fields are ignored.  The new segment ignores the
> > flags field.  Overloading the PT_GNU_STACK segment seems a good
> > idea to me since it is totally backward and forward compatible.
>
> this is not correct ... on Blackfin, we use the other attributes of
> PT_GNU_STACK (like the memsize field) to control the stack size (since
> Blackfin is a no-mmu)

to be a little more precise ... all Linux ports which support FDPIC ELF 
utilize the memsize field to set the stack size of the application, so this 
isnt Blackfin-specific
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Daniel Jacobowitz]

On Thu, Aug 16, 2007 at 10:11:05AM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 06:53:58AM -0700, H.J. Lu wrote:
> > On Thu, Aug 16, 2007 at 09:43:10AM -0400, Daniel Jacobowitz wrote:
> > > I don't think this patch is a good idea.  I would prefer to back it
> > > out until there is a clear use case and support from at least one
> > > consumer.
> > 
> > I have got a request to mark a binary for a totally different ABI than
> > the normal one. They wanted to use ELF header to mark the ABI. But the
> > bits in ELF header are very limited. The attribute section is
> > perfect for this.
> 
> I stand by my request.  Please at least talk to Jakub about this
> before you go changing program headers.

Also, I see that ARM defined a separate ARM-specific program header
for the sort of information you want; look for PT_ARM_ARCHEXT in
http://www.arm.com/pdfs/aaelf.pdf.

The contents are deliberately not in the same format as
.ARM.attributes, because .ARM.attributes is not designed to be
efficient to parse.  Also a lot of it - e.g. per-function and per-file
attributes, which the GNU tools do not yet generate - is uninteresting
to the loader.

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[H.J. Lu]

On Thu, Aug 16, 2007 at 03:00:40PM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 10:11:05AM -0400, Daniel Jacobowitz wrote:
> > On Thu, Aug 16, 2007 at 06:53:58AM -0700, H.J. Lu wrote:
> > > On Thu, Aug 16, 2007 at 09:43:10AM -0400, Daniel Jacobowitz wrote:
> > > > I don't think this patch is a good idea.  I would prefer to back it
> > > > out until there is a clear use case and support from at least one
> > > > consumer.
> > > 
> > > I have got a request to mark a binary for a totally different ABI than
> > > the normal one. They wanted to use ELF header to mark the ABI. But the
> > > bits in ELF header are very limited. The attribute section is
> > > perfect for this.
> > 
> > I stand by my request.  Please at least talk to Jakub about this
> > before you go changing program headers.
> 
> Also, I see that ARM defined a separate ARM-specific program header
> for the sort of information you want; look for PT_ARM_ARCHEXT in
> http://www.arm.com/pdfs/aaelf.pdf.
> 
> The contents are deliberately not in the same format as
> .ARM.attributes, because .ARM.attributes is not designed to be
> efficient to parse.  Also a lot of it - e.g. per-function and per-file
> attributes, which the GNU tools do not yet generate - is uninteresting
> to the loader.

For the attribute info in executable and shared library, there
should be no difference between linker and loader. Do we need
the full content of .ARM.attributes section in executable and shared
library? It sounds to me that PT_ARM_ARCHEXT can just have a
.ARM.attributes section which can be generated from .ARM.attributes
in input relocatable files.  .ARM.attributes in executable and shared
library can smaller and different from .ARM.attributes in relocatable
files. Readelf will check PT_ARM_ARCHEXT to see how .ARM.attributes
should be processed.


H.J.

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Daniel Jacobowitz]

On Thu, Aug 16, 2007 at 02:05:08PM -0700, H.J. Lu wrote:
> For the attribute info in executable and shared library, there
> should be no difference between linker and loader. Do we need
> the full content of .ARM.attributes section in executable and shared
> library? It sounds to me that PT_ARM_ARCHEXT can just have a
> .ARM.attributes section which can be generated from .ARM.attributes
> in input relocatable files.  .ARM.attributes in executable and shared
> library can smaller and different from .ARM.attributes in relocatable
> files. Readelf will check PT_ARM_ARCHEXT to see how .ARM.attributes
> should be processed.

I think that it is reasonably likely that some tools (e.g. ld and gdb)
will need more information than ld.so.

Since I have serious misgivings about this patch, there are no uses
yet, and Mike has said you've broken Blackfin and FRV uClinux, could
you please revert it until we have a better plan in place?  Thanks.

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[H.J. Lu]

On Fri, Aug 17, 2007 at 08:21:01AM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 02:05:08PM -0700, H.J. Lu wrote:
> > For the attribute info in executable and shared library, there
> > should be no difference between linker and loader. Do we need
> > the full content of .ARM.attributes section in executable and shared
> > library? It sounds to me that PT_ARM_ARCHEXT can just have a
> > .ARM.attributes section which can be generated from .ARM.attributes
> > in input relocatable files.  .ARM.attributes in executable and shared
> > library can smaller and different from .ARM.attributes in relocatable
> > files. Readelf will check PT_ARM_ARCHEXT to see how .ARM.attributes
> > should be processed.
> 
> I think that it is reasonably likely that some tools (e.g. ld and gdb)
> will need more information than ld.so.
> 
> Since I have serious misgivings about this patch, there are no uses
> yet, and Mike has said you've broken Blackfin and FRV uClinux, could
> you please revert it until we have a better plan in place?  Thanks.
> 

Done.


H.J.

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Daniel Jacobowitz]

On Fri, Aug 17, 2007 at 06:16:47AM -0700, H.J. Lu wrote:
> Done.

Thanks!

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

[Paul Brook]

> > > > I don't think this patch is a good idea.  I would prefer to back it
> > > > out until there is a clear use case and support from at least one
> > > > consumer.
> > >
> > > I have got a request to mark a binary for a totally different ABI than
> > > the normal one. They wanted to use ELF header to mark the ABI. But the
> > > bits in ELF header are very limited. The attribute section is
> > > perfect for this.
> >
> > I stand by my request.  Please at least talk to Jakub about this
> > before you go changing program headers.
>
> Also, I see that ARM defined a separate ARM-specific program header
> for the sort of information you want; look for PT_ARM_ARCHEXT in
> http://www.arm.com/pdfs/aaelf.pdf.
>
> The contents are deliberately not in the same format as
> .ARM.attributes, because .ARM.attributes is not designed to be
> efficient to parse.  Also a lot of it - e.g. per-function and per-file
> attributes, which the GNU tools do not yet generate - is uninteresting
> to the loader.

I can confirm that the ARM EABI .ARM.attributes section is only intended for 
use by the static linker. I can't find anything in the docs, but the intent 
of the EABI committee was that it should not be an allocateable section.
It's way too big and complicated to be suitable for use at runtime.

Paul