making aliases into the middle of a structure

making aliases into the middle of a structure

[Zack Weinberg]

Consider this bit of code.

struct s
{
  int a, b;
};

struct s x = { 0, 0 };

extern __typeof(x.b) y __attribute__ ((alias("x.b")));

The goal is to have x.b and y refer to the same memory location.  I am
aware that this is somewhat perverse, but there are legitimate reasons
(binary compatibility) for it.

If gcc were to translate this into

.data
.globl x
        .align 4
        .type    x,@object
        .size    x,8
x:
        .zero   8
.globl y
        .set    y, x+4

then the assembler would generate a correct object module, and
references to `x.b' and `y' would indeed operate on the same memory
location.

Unfortunately this is not what gcc produces; instead I get

.data
.globl x
        .align 4
        .type    x,@object
        .size    x,8
x:
        .zero   8
.globl y
        .set    y,x.b


The assembler generates an undefined reference to the symbol `x.b' and
forgets about `y'.

I have experimented with workarounds involving offsetof();
unfortunately, the best this can do is

	.set y,x + ((size_t) &((s *)0)->b)

which is not an expression that the assembler can evaluate.  I do not
want to write a raw assembly module, because that will break if the
padding inside the structure, or the sizes of the component types,
change.

Any suggestions?

zw

Re: making aliases into the middle of a structure

[Alexandre Oliva]

On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:

> extern __typeof(x.b) y __attribute__ ((alias("x.b")));

This can't work.  The alias attribute defines an alias to a *symbol*,
not to an arbitrary expression.  Since you may have to get quite
platform-specific because of the potential need for leading
underscores, why don't you compute the offset, say, in the configure
script, then #define the appropriate alias string?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: making aliases into the middle of a structure

[Zack Weinberg]

On 22 Apr 1999 15:24:46 -0300, Alexandre Oliva wrote:
>On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>
>> extern __typeof(x.b) y __attribute__ ((alias("x.b")));
>
>This can't work.  The alias attribute defines an alias to a *symbol*,
>not to an arbitrary expression. 

I don't see that it would be terribly hard to extend alias so it could
handle SYMBOL_REFs and COMPONENT_REFs as well as strings.

>Since you may have to get quite
>platform-specific because of the potential need for leading
>underscores, 

This is already handled in the real framework; the above was a
stripped down example.

>why don't you compute the offset, say, in the configure
>script, then #define the appropriate alias string?

Because the preprocessor can't compute offsetof() all the way down;
I'd have to compile and run a test program.  Which loses when
cross-compiling.

zw

Re: making aliases into the middle of a structure

[Alexandre Oliva]

On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:

> On 22 Apr 1999 15:24:46 -0300, Alexandre Oliva wrote:
>> On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>> 
>>> extern __typeof(x.b) y __attribute__ ((alias("x.b")));
>> 
>> This can't work.  The alias attribute defines an alias to a *symbol*,
>> not to an arbitrary expression. 

> I don't see that it would be terribly hard to extend alias so it could
> handle SYMBOL_REFs and COMPONENT_REFs as well as strings.

That would probably be a good idea.  alias could accept an arbitrary
expression.  If it's an lvalue within a global symbol, it will define
an actual alias, otherwise it could just emit an error or ``construct
a temporary and bind the reference to it'', to put it in C++ terms :-) 

>> why don't you compute the offset, say, in the configure
>> script, then #define the appropriate alias string?

> Because the preprocessor can't compute offsetof() all the way down;
> I'd have to compile and run a test program.  Which loses when
> cross-compiling.

Well, you could try to extract this information from the assembly
code, or from some RTL dump (since you're bound to gcc anyway), but I
wouldn't like to be the one to implement it :-)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: making aliases into the middle of a structure

[Zack Weinberg]

On 22 Apr 1999 15:38:16 -0300, Alexandre Oliva wrote:
>On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>
>> On 22 Apr 1999 15:24:46 -0300, Alexandre Oliva wrote:
>>> On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>>> 
>>>> extern __typeof(x.b) y __attribute__ ((alias("x.b")));
>>> 
>>> This can't work.  The alias attribute defines an alias to a *symbol*,
>>> not to an arbitrary expression. 
>
>> I don't see that it would be terribly hard to extend alias so it could
>> handle SYMBOL_REFs and COMPONENT_REFs as well as strings.
>
>That would probably be a good idea.  alias could accept an arbitrary
>expression.  If it's an lvalue within a global symbol, it will define
>an actual alias, otherwise it could just emit an error or ``construct
>a temporary and bind the reference to it'', to put it in C++ terms :-) 

It turns out to be relatively simple to implement, too (at least if
you don't try to construct temporaries).  The appended patch is
a proof-of-concept; I don't expect it'll make it into 1.2.  I had to
introduce a new MD macro, ASM_OUTPUT_OFFSET_DEF, and the patch does
not modify the relevant tm.h files, only defaults.h (so it works only
with assemblers that use .set).  Any front-end that calls
assemble_alias also needs to be adjusted; none of the ones in current
CVS do.

The subset of this patch that lets attribute alias accept bare
identifiers is trivial, and it'd be nice if that got into 1.2.

[As an aside, get_inner_reference has a rather nonintuitive name...]

zw

1999-04-22 17:22 -0400  Zack Weinberg  <zack@rabi.phys.columbia.edu>

	* c-common.c (decl_attributes: A_ALIAS): Accept an
	IDENTIFIER_NODE or COMPONENT_REF in args.  If we get a
	COMPONENT_REF, sanity-check it (no bitfields, no non-lvalues,
	no variable offsets) and pass the component offset on to
	assemble_alias.
	* varasm.c (assemble_alias): Add `offset' argument.  If it's
	nonzero, use ASM_OUTPUT_OFFSET_DEF to output the alias
	definition with its offset from the base symbol.
	* defaults.h (ASM_OUTPUT_OFFSET_DEF): New macro, for
	outputting alias defns of the form ".set b,a+4".
	* output.h: Update prototype of assemble_alias.

===================================================================
Index: c-common.c
--- c-common.c	1999/04/13 21:04:06	1.56
+++ c-common.c	1999/04/22 21:20:34
@@ -891,20 +891,62 @@
 	  else if (decl_function_context (decl) == 0)
 	    {
 	      tree id;
+	      int offset;
 
 	      id = TREE_VALUE (args);
-	      if (TREE_CODE (id) != STRING_CST)
+	      if (TREE_CODE (id) == STRING_CST)
 		{
-		  error ("alias arg not a string");
+		  id = get_identifier (TREE_STRING_POINTER (id));
+		  offset = 0;
+		}
+	      else if (TREE_CODE (id) == IDENTIFIER_NODE)
+		{
+		  offset = 0;
+		}
+	      else if (TREE_CODE (id) == COMPONENT_REF)
+		{
+		  if (! lvalue_p (TREE_OPERAND (id, 0)))
+		    {
+		      error ("alias arg not an lvalue expression");
+		      break;
+		    }
+		  else if (DECL_C_BIT_FIELD (TREE_OPERAND (id, 1)))
+		    {
+		      error ("cannot set alias to bitfield `%s'",
+			     IDENTIFIER_POINTER (DECL_NAME (
+						      TREE_OPERAND (id, 1))));
+		      break;
+		    }
+		  else
+		    {
+		      int boffset, bsiz, puns, pvol, palign;
+		      tree poff, newid;
+		      enum machine_mode mode;
+		      
+		      newid = get_inner_reference (id, &bsiz, &boffset, &poff,
+						&mode, &puns, &pvol, &palign);
+		      if (poff != NULL_TREE)
+			{
+			  error ("cannot set alias to variably offset field `%s'",
+				 IDENTIFIER_POINTER (DECL_NAME (
+						       TREE_OPERAND (id, 1))));
+			  break;
+			}
+		      id = DECL_NAME (newid);
+		      offset = boffset / BITS_PER_UNIT;
+		    }
+		}
+	      else
+		{
+		  error ("alias arg not a string or lvalue expression");
 		  break;
 		}
-	      id = get_identifier (TREE_STRING_POINTER (id));
 
 	      if (TREE_CODE (decl) == FUNCTION_DECL)
 		DECL_INITIAL (decl) = error_mark_node;
 	      else
 		DECL_EXTERNAL (decl) = 0;
-	      assemble_alias (decl, id);
+	      assemble_alias (decl, id, offset);
 	    }
 	  else
 	    warning ("`%s' attribute ignored", IDENTIFIER_POINTER (name));
===================================================================
Index: varasm.c
--- varasm.c	1999/03/28 15:35:04	1.57
+++ varasm.c	1999/04/22 21:20:36
@@ -4334,8 +4334,9 @@
 }
 
 void
-assemble_alias (decl, target)
+assemble_alias (decl, target, offset)
      tree decl, target ATTRIBUTE_UNUSED;
+     int offset ATTRIBUTE_UNUSED;
 {
   char *name;
 
@@ -4355,14 +4356,26 @@
 	ASM_GLOBALIZE_LABEL (asm_out_file, name);
     }
 
-  ASM_OUTPUT_DEF (asm_out_file, name, IDENTIFIER_POINTER (target));
+  if (offset == 0)
+    ASM_OUTPUT_DEF (asm_out_file, name, IDENTIFIER_POINTER (target));
+  else
+#ifdef ASM_OUTPUT_OFFSET_DEF
+    ASM_OUTPUT_OFFSET_DEF (asm_out_file, name,
+			   IDENTIFIER_POINTER (target), offset);
+#else
+  warning ("offset alias definitions not supported in this configuration; ignored");
+#endif
+
   TREE_ASM_WRITTEN (decl) = 1;
 #else
 #ifdef ASM_OUTPUT_WEAK_ALIAS
   if (! DECL_WEAK (decl))
     warning ("only weak aliases are supported in this configuration");
 
-  ASM_OUTPUT_WEAK_ALIAS (asm_out_file, name, IDENTIFIER_POINTER (target));
+  if (offset == 0)
+    ASM_OUTPUT_WEAK_ALIAS (asm_out_file, name, IDENTIFIER_POINTER (target));
+  else
+    warning ("offset alias definitions not supported in this configuration; ignored");
   TREE_ASM_WRITTEN (decl) = 1;
 #else
   warning ("alias definitions not supported in this configuration; ignored");
===================================================================
Index: defaults.h
--- defaults.h	1999/02/27 22:21:57	1.7
+++ defaults.h	1999/04/22 21:20:36
@@ -116,6 +116,15 @@
 	fprintf (FILE, "\n");						\
   } while (0)
 #endif
+#ifndef ASM_OUTPUT_OFFSET_DEF
+#define ASM_OUTPUT_OFFSET_DEF(FILE,LABEL1,LABEL2,OFFSET)		\
+ do {	fprintf ((FILE), "\t%s\t", SET_ASM_OP);				\
+	assemble_name (FILE, LABEL1);					\
+	fprintf (FILE, ",");						\
+	assemble_name (FILE, LABEL2);					\
+	fprintf (FILE, "+%d\n", OFFSET);				\
+  } while (0)
+#endif
 #endif
 
 /* This is how to output a reference to a user-level label named NAME.  */
===================================================================
Index: output.h
--- output.h	1999/04/18 13:09:18	1.23
+++ output.h	1999/04/22 21:20:36
@@ -207,7 +207,7 @@
 /* Output alignment directive to align for constant expression EXP.  */
 extern void assemble_constant_align	PROTO((tree));
 
-extern void assemble_alias		PROTO((tree, tree));
+extern void assemble_alias		PROTO((tree, tree, int));
 
 /* Output a string of literal assembler code
    for an `asm' keyword used between functions.  */

Re: making aliases into the middle of a structure

[Richard Henderson]

On Thu, Apr 22, 1999 at 05:31:38PM -0400, Zack Weinberg wrote:
> >That would probably be a good idea.  alias could accept an arbitrary
> >expression.  If it's an lvalue within a global symbol, it will define
> >an actual alias, otherwise it could just emit an error or ``construct
> >a temporary and bind the reference to it'', to put it in C++ terms :-) 
>
> It turns out to be relatively simple to implement, too (at least if
> you don't try to construct temporaries).  The appended patch is
> a proof-of-concept; I don't expect it'll make it into 1.2.  I had to
> introduce a new MD macro, ASM_OUTPUT_OFFSET_DEF...

This is a very bad way to implement this.  You're hiding from the
optimizers the fact that you've got two global symbols that alias.

The only way this will ever work is for you to adjust the DECL_RTL
of `y' such that the aliasing is visible.  You'd have something like

	(const (plus (symbol_ref "x") (const_int 42)))

for a global; something obvious for stack-local objects.  And of 
course this is only going to work without -fno-strict-aliasing if
the programmer makes sure that the types correspond.  But that, I 
think, is not your problem.

If you like to emit `y' as a global symbol too, that's fine. 

BTW, you don't need the ifdef in varasm.c if you have a version
in defaults.h.


r~

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 15:23:59 -0700, Richard Henderson wrote:
>On Thu, Apr 22, 1999 at 05:31:38PM -0400, Zack Weinberg wrote:
>> >That would probably be a good idea.  alias could accept an arbitrary
>> >expression.  If it's an lvalue within a global symbol, it will define
>> >an actual alias, otherwise it could just emit an error or ``construct
>> >a temporary and bind the reference to it'', to put it in C++ terms :-) 
>>
>> It turns out to be relatively simple to implement, too (at least if
>> you don't try to construct temporaries).  The appended patch is
>> a proof-of-concept; I don't expect it'll make it into 1.2.  I had to
>> introduce a new MD macro, ASM_OUTPUT_OFFSET_DEF...
>
>This is a very bad way to implement this.  You're hiding from the
>optimizers the fact that you've got two global symbols that alias.

Huh.  Why isn't this a problem for the existing symbol-alias
mechanism?  And what am I to do about references from another source
file?  The intended use of this feature is isolated in a file that
does nothing but export `x' and `y'.

>The only way this will ever work is for you to adjust the DECL_RTL
>of `y' such that the aliasing is visible.  You'd have something like
>
>	(const (plus (symbol_ref "x") (const_int 42)))
>
>for a global; something obvious for stack-local objects.  

Ok, if you don't mind my asking the dumb question, how do I do that?
The tree->rtl conversion isn't exactly documented.

>And of course this is only going to work without -fno-strict-aliasing
>if the programmer makes sure that the types correspond.  But that, I
>think, is not your problem.

Maybe I should verify that the types correspond inside decl_attributes.

>If you like to emit `y' as a global symbol too, that's fine. 

In this context, it's kinda necessary.

>BTW, you don't need the ifdef in varasm.c if you have a version
>in defaults.h.

The defaults.h version is only defined if SET_ASM_OP is available.

zw

Re: making aliases into the middle of a structure

[Richard Henderson]

On Fri, Apr 23, 1999 at 07:27:32PM -0400, Zack Weinberg wrote:
> Huh.  Why isn't this a problem for the existing symbol-alias
> mechanism? 

Um.. maybe it is?  I havn't looked.

> And what am I to do about references from another source
> file?  The intended use of this feature is isolated in a file that
> does nothing but export `x' and `y'.

Well, as long as you don't reference both `x' and `y' in the
same function, you don't care really.

> Ok, if you don't mind my asking the dumb question, how do I do that?
> The tree->rtl conversion isn't exactly documented.

Lets see..  you'd get the offset with get_inner_reference or
something.  You'd take that and the base symbol and do something like

  // For a global, DECL_RTL is of the form (mem (symbol_ref))

  DECL_RTL (alias) = gen_rtx_MEM (TREE_MODE (alias),
				  plus_constant (XEXP (DECL_RTL (base), 0),
						 offset));
  MEM_ALIAS_SET (DECL_RTL (alias)) = get_alias_set (TREE_TYPE (alias));

I think.  This is off the top of my head.


r~

Re: making aliases into the middle of a structure

[Richard Henderson]

On Fri, Apr 23, 1999 at 07:27:32PM -0400, Zack Weinberg wrote:
> Huh.  Why isn't this a problem for the existing symbol-alias
> mechanism? 

Um.. maybe it is?  I havn't looked.

> And what am I to do about references from another source
> file?  The intended use of this feature is isolated in a file that
> does nothing but export `x' and `y'.

Well, as long as you don't reference both `x' and `y' in the
same function, you don't care really.

> Ok, if you don't mind my asking the dumb question, how do I do that?
> The tree->rtl conversion isn't exactly documented.

Lets see..  you'd get the offset with get_inner_reference or
something.  You'd take that and the base symbol and do something like

  // For a global, DECL_RTL is of the form (mem (symbol_ref))

  DECL_RTL (alias) = gen_rtx_MEM (TREE_MODE (alias),
				  plus_constant (XEXP (DECL_RTL (base), 0),
						 offset));
  MEM_ALIAS_SET (DECL_RTL (alias)) = get_alias_set (TREE_TYPE (alias));

I think.  This is off the top of my head.


r~

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 15:23:59 -0700, Richard Henderson wrote:
>On Thu, Apr 22, 1999 at 05:31:38PM -0400, Zack Weinberg wrote:
>> >That would probably be a good idea.  alias could accept an arbitrary
>> >expression.  If it's an lvalue within a global symbol, it will define
>> >an actual alias, otherwise it could just emit an error or ``construct
>> >a temporary and bind the reference to it'', to put it in C++ terms :-) 
>>
>> It turns out to be relatively simple to implement, too (at least if
>> you don't try to construct temporaries).  The appended patch is
>> a proof-of-concept; I don't expect it'll make it into 1.2.  I had to
>> introduce a new MD macro, ASM_OUTPUT_OFFSET_DEF...
>
>This is a very bad way to implement this.  You're hiding from the
>optimizers the fact that you've got two global symbols that alias.

Huh.  Why isn't this a problem for the existing symbol-alias
mechanism?  And what am I to do about references from another source
file?  The intended use of this feature is isolated in a file that
does nothing but export `x' and `y'.

>The only way this will ever work is for you to adjust the DECL_RTL
>of `y' such that the aliasing is visible.  You'd have something like
>
>	(const (plus (symbol_ref "x") (const_int 42)))
>
>for a global; something obvious for stack-local objects.  

Ok, if you don't mind my asking the dumb question, how do I do that?
The tree->rtl conversion isn't exactly documented.

>And of course this is only going to work without -fno-strict-aliasing
>if the programmer makes sure that the types correspond.  But that, I
>think, is not your problem.

Maybe I should verify that the types correspond inside decl_attributes.

>If you like to emit `y' as a global symbol too, that's fine. 

In this context, it's kinda necessary.

>BTW, you don't need the ifdef in varasm.c if you have a version
>in defaults.h.

The defaults.h version is only defined if SET_ASM_OP is available.

zw

Re: making aliases into the middle of a structure

[Richard Henderson]

On Thu, Apr 22, 1999 at 05:31:38PM -0400, Zack Weinberg wrote:
> >That would probably be a good idea.  alias could accept an arbitrary
> >expression.  If it's an lvalue within a global symbol, it will define
> >an actual alias, otherwise it could just emit an error or ``construct
> >a temporary and bind the reference to it'', to put it in C++ terms :-) 
>
> It turns out to be relatively simple to implement, too (at least if
> you don't try to construct temporaries).  The appended patch is
> a proof-of-concept; I don't expect it'll make it into 1.2.  I had to
> introduce a new MD macro, ASM_OUTPUT_OFFSET_DEF...

This is a very bad way to implement this.  You're hiding from the
optimizers the fact that you've got two global symbols that alias.

The only way this will ever work is for you to adjust the DECL_RTL
of `y' such that the aliasing is visible.  You'd have something like

	(const (plus (symbol_ref "x") (const_int 42)))

for a global; something obvious for stack-local objects.  And of 
course this is only going to work without -fno-strict-aliasing if
the programmer makes sure that the types correspond.  But that, I 
think, is not your problem.

If you like to emit `y' as a global symbol too, that's fine. 

BTW, you don't need the ifdef in varasm.c if you have a version
in defaults.h.


r~

Re: making aliases into the middle of a structure

[Zack Weinberg]

On 22 Apr 1999 15:38:16 -0300, Alexandre Oliva wrote:
>On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>
>> On 22 Apr 1999 15:24:46 -0300, Alexandre Oliva wrote:
>>> On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>>> 
>>>> extern __typeof(x.b) y __attribute__ ((alias("x.b")));
>>> 
>>> This can't work.  The alias attribute defines an alias to a *symbol*,
>>> not to an arbitrary expression. 
>
>> I don't see that it would be terribly hard to extend alias so it could
>> handle SYMBOL_REFs and COMPONENT_REFs as well as strings.
>
>That would probably be a good idea.  alias could accept an arbitrary
>expression.  If it's an lvalue within a global symbol, it will define
>an actual alias, otherwise it could just emit an error or ``construct
>a temporary and bind the reference to it'', to put it in C++ terms :-) 

It turns out to be relatively simple to implement, too (at least if
you don't try to construct temporaries).  The appended patch is
a proof-of-concept; I don't expect it'll make it into 1.2.  I had to
introduce a new MD macro, ASM_OUTPUT_OFFSET_DEF, and the patch does
not modify the relevant tm.h files, only defaults.h (so it works only
with assemblers that use .set).  Any front-end that calls
assemble_alias also needs to be adjusted; none of the ones in current
CVS do.

The subset of this patch that lets attribute alias accept bare
identifiers is trivial, and it'd be nice if that got into 1.2.

[As an aside, get_inner_reference has a rather nonintuitive name...]

zw

1999-04-22 17:22 -0400  Zack Weinberg  <zack@rabi.phys.columbia.edu>

	* c-common.c (decl_attributes: A_ALIAS): Accept an
	IDENTIFIER_NODE or COMPONENT_REF in args.  If we get a
	COMPONENT_REF, sanity-check it (no bitfields, no non-lvalues,
	no variable offsets) and pass the component offset on to
	assemble_alias.
	* varasm.c (assemble_alias): Add `offset' argument.  If it's
	nonzero, use ASM_OUTPUT_OFFSET_DEF to output the alias
	definition with its offset from the base symbol.
	* defaults.h (ASM_OUTPUT_OFFSET_DEF): New macro, for
	outputting alias defns of the form ".set b,a+4".
	* output.h: Update prototype of assemble_alias.

===================================================================
Index: c-common.c
--- c-common.c	1999/04/13 21:04:06	1.56
+++ c-common.c	1999/04/22 21:20:34
@@ -891,20 +891,62 @@
 	  else if (decl_function_context (decl) == 0)
 	    {
 	      tree id;
+	      int offset;
 
 	      id = TREE_VALUE (args);
-	      if (TREE_CODE (id) != STRING_CST)
+	      if (TREE_CODE (id) == STRING_CST)
 		{
-		  error ("alias arg not a string");
+		  id = get_identifier (TREE_STRING_POINTER (id));
+		  offset = 0;
+		}
+	      else if (TREE_CODE (id) == IDENTIFIER_NODE)
+		{
+		  offset = 0;
+		}
+	      else if (TREE_CODE (id) == COMPONENT_REF)
+		{
+		  if (! lvalue_p (TREE_OPERAND (id, 0)))
+		    {
+		      error ("alias arg not an lvalue expression");
+		      break;
+		    }
+		  else if (DECL_C_BIT_FIELD (TREE_OPERAND (id, 1)))
+		    {
+		      error ("cannot set alias to bitfield `%s'",
+			     IDENTIFIER_POINTER (DECL_NAME (
+						      TREE_OPERAND (id, 1))));
+		      break;
+		    }
+		  else
+		    {
+		      int boffset, bsiz, puns, pvol, palign;
+		      tree poff, newid;
+		      enum machine_mode mode;
+		      
+		      newid = get_inner_reference (id, &bsiz, &boffset, &poff,
+						&mode, &puns, &pvol, &palign);
+		      if (poff != NULL_TREE)
+			{
+			  error ("cannot set alias to variably offset field `%s'",
+				 IDENTIFIER_POINTER (DECL_NAME (
+						       TREE_OPERAND (id, 1))));
+			  break;
+			}
+		      id = DECL_NAME (newid);
+		      offset = boffset / BITS_PER_UNIT;
+		    }
+		}
+	      else
+		{
+		  error ("alias arg not a string or lvalue expression");
 		  break;
 		}
-	      id = get_identifier (TREE_STRING_POINTER (id));
 
 	      if (TREE_CODE (decl) == FUNCTION_DECL)
 		DECL_INITIAL (decl) = error_mark_node;
 	      else
 		DECL_EXTERNAL (decl) = 0;
-	      assemble_alias (decl, id);
+	      assemble_alias (decl, id, offset);
 	    }
 	  else
 	    warning ("`%s' attribute ignored", IDENTIFIER_POINTER (name));
===================================================================
Index: varasm.c
--- varasm.c	1999/03/28 15:35:04	1.57
+++ varasm.c	1999/04/22 21:20:36
@@ -4334,8 +4334,9 @@
 }
 
 void
-assemble_alias (decl, target)
+assemble_alias (decl, target, offset)
      tree decl, target ATTRIBUTE_UNUSED;
+     int offset ATTRIBUTE_UNUSED;
 {
   char *name;
 
@@ -4355,14 +4356,26 @@
 	ASM_GLOBALIZE_LABEL (asm_out_file, name);
     }
 
-  ASM_OUTPUT_DEF (asm_out_file, name, IDENTIFIER_POINTER (target));
+  if (offset == 0)
+    ASM_OUTPUT_DEF (asm_out_file, name, IDENTIFIER_POINTER (target));
+  else
+#ifdef ASM_OUTPUT_OFFSET_DEF
+    ASM_OUTPUT_OFFSET_DEF (asm_out_file, name,
+			   IDENTIFIER_POINTER (target), offset);
+#else
+  warning ("offset alias definitions not supported in this configuration; ignored");
+#endif
+
   TREE_ASM_WRITTEN (decl) = 1;
 #else
 #ifdef ASM_OUTPUT_WEAK_ALIAS
   if (! DECL_WEAK (decl))
     warning ("only weak aliases are supported in this configuration");
 
-  ASM_OUTPUT_WEAK_ALIAS (asm_out_file, name, IDENTIFIER_POINTER (target));
+  if (offset == 0)
+    ASM_OUTPUT_WEAK_ALIAS (asm_out_file, name, IDENTIFIER_POINTER (target));
+  else
+    warning ("offset alias definitions not supported in this configuration; ignored");
   TREE_ASM_WRITTEN (decl) = 1;
 #else
   warning ("alias definitions not supported in this configuration; ignored");
===================================================================
Index: defaults.h
--- defaults.h	1999/02/27 22:21:57	1.7
+++ defaults.h	1999/04/22 21:20:36
@@ -116,6 +116,15 @@
 	fprintf (FILE, "\n");						\
   } while (0)
 #endif
+#ifndef ASM_OUTPUT_OFFSET_DEF
+#define ASM_OUTPUT_OFFSET_DEF(FILE,LABEL1,LABEL2,OFFSET)		\
+ do {	fprintf ((FILE), "\t%s\t", SET_ASM_OP);				\
+	assemble_name (FILE, LABEL1);					\
+	fprintf (FILE, ",");						\
+	assemble_name (FILE, LABEL2);					\
+	fprintf (FILE, "+%d\n", OFFSET);				\
+  } while (0)
+#endif
 #endif
 
 /* This is how to output a reference to a user-level label named NAME.  */
===================================================================
Index: output.h
--- output.h	1999/04/18 13:09:18	1.23
+++ output.h	1999/04/22 21:20:36
@@ -207,7 +207,7 @@
 /* Output alignment directive to align for constant expression EXP.  */
 extern void assemble_constant_align	PROTO((tree));
 
-extern void assemble_alias		PROTO((tree, tree));
+extern void assemble_alias		PROTO((tree, tree, int));
 
 /* Output a string of literal assembler code
    for an `asm' keyword used between functions.  */

Re: making aliases into the middle of a structure

[Jeffrey A Law]

  In message < org15s33hj.fsf@lua.lbi.dcc.unicamp.br >you write:
  > > Because the preprocessor can't compute offsetof() all the way down;
  > > I'd have to compile and run a test program.  Which loses when
  > > cross-compiling.
  > 
  > Well, you could try to extract this information from the assembly
  > code, or from some RTL dump (since you're bound to gcc anyway), but I
  > wouldn't like to be the one to implement it :-)
Cygnus implemented a switch to have the compiler dump offsets for fields
within structures in a format intended to be used by assembly code.

It's not something we've used a lot and haven't ever thought it worth
the effort to clean it up and submit it to egcs.

I've been kicking around the idea of using that code to build a testsuite
to look for unexpected changes in structure layouts between releases as
one component of a wider1 ABI compatibility testing plan.

Ie, we build a repository of tests which define a bunch of structs, unions,
classes.  We compile those tests with the magic option which records the
offset for each field within the structure.  We do this for each target we
care about.

Then we can compile a later release and compare the offsets for that target
to ensure they have not changed.

It's not a perfect solution for ABI testing, but it's a small step we can
use as a building block.  Will it actually happen -- I don't know.  It's
still a blue sky project.

Jeff

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 00:14:34 -0600, Jeffrey A Law wrote:
>
>  In message < org15s33hj.fsf@lua.lbi.dcc.unicamp.br >you write:
>  > > Because the preprocessor can't compute offsetof() all the way down;
>  > > I'd have to compile and run a test program.  Which loses when
>  > > cross-compiling.
>  > 
>  > Well, you could try to extract this information from the assembly
>  > code, or from some RTL dump (since you're bound to gcc anyway), but I
>  > wouldn't like to be the one to implement it :-)
>Cygnus implemented a switch to have the compiler dump offsets for fields
>within structures in a format intended to be used by assembly code.
>
>It's not something we've used a lot and haven't ever thought it worth
>the effort to clean it up and submit it to egcs.

This is a cute idea, and I could think of uses in libc, but it doesn't
really solve my current problem (without excessive magic).  I'd much
rather be able to write

extern int var __attribute__ ((alias (structure.field)));

which is what the patch I sent yesterday implements.

Incidentally, I found what I think is a GAS bug: it forgets
aliases to symbols allocated with .comm.  For example:

int common;
extern int alias __attribute__ ((alias("common")));

`alias' will not be defined in the object file.  The assembly dump
looks correct to me.

zw

Re: making aliases into the middle of a structure

[Richard Henderson]

On Fri, Apr 23, 1999 at 01:40:34PM -0400, Zack Weinberg wrote:
> int common;
> extern int alias __attribute__ ((alias("common")));
> 
> `alias' will not be defined in the object file.  The assembly dump
> looks correct to me.

This is not a bug.  This is impossible to represent 
in the object file.  I believe SOM can do it if you
feel like hurting yourself...  ;-)


r~

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 15:54:17 -0700, Richard Henderson wrote:
>On Fri, Apr 23, 1999 at 01:40:34PM -0400, Zack Weinberg wrote:
>> int common;
>> extern int alias __attribute__ ((alias("common")));
>> 
>> `alias' will not be defined in the object file.  The assembly dump
>> looks correct to me.
>
>This is not a bug.  This is impossible to represent 
>in the object file.  I believe SOM can do it if you
>feel like hurting yourself...  ;-)

I didn't know that.  It'd be nice if the assembler would complain
instead of silently discarding the symbol.

zw

Re: making aliases into the middle of a structure

[Andreas Schwab]

Zack Weinberg <zack@rabi.columbia.edu> writes:

|> On Fri, 23 Apr 1999 15:54:17 -0700, Richard Henderson wrote:
|> >On Fri, Apr 23, 1999 at 01:40:34PM -0400, Zack Weinberg wrote:
|> >> int common;
|> >> extern int alias __attribute__ ((alias("common")));
|> >> 
|> >> `alias' will not be defined in the object file.  The assembly dump
|> >> looks correct to me.
|> >
|> >This is not a bug.  This is impossible to represent 
|> >in the object file.  I believe SOM can do it if you
|> >feel like hurting yourself...  ;-)
|> 
|> I didn't know that.  It'd be nice if the assembler would complain
|> instead of silently discarding the symbol.

Compile with -fno-common.  Common symbols are evil anyway.

Andreas.

Re: making aliases into the middle of a structure

[Andreas Schwab]

Zack Weinberg <zack@rabi.columbia.edu> writes:

|> On Fri, 23 Apr 1999 15:54:17 -0700, Richard Henderson wrote:
|> >On Fri, Apr 23, 1999 at 01:40:34PM -0400, Zack Weinberg wrote:
|> >> int common;
|> >> extern int alias __attribute__ ((alias("common")));
|> >> 
|> >> `alias' will not be defined in the object file.  The assembly dump
|> >> looks correct to me.
|> >
|> >This is not a bug.  This is impossible to represent 
|> >in the object file.  I believe SOM can do it if you
|> >feel like hurting yourself...  ;-)
|> 
|> I didn't know that.  It'd be nice if the assembler would complain
|> instead of silently discarding the symbol.

Compile with -fno-common.  Common symbols are evil anyway.

Andreas.

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 15:54:17 -0700, Richard Henderson wrote:
>On Fri, Apr 23, 1999 at 01:40:34PM -0400, Zack Weinberg wrote:
>> int common;
>> extern int alias __attribute__ ((alias("common")));
>> 
>> `alias' will not be defined in the object file.  The assembly dump
>> looks correct to me.
>
>This is not a bug.  This is impossible to represent 
>in the object file.  I believe SOM can do it if you
>feel like hurting yourself...  ;-)

I didn't know that.  It'd be nice if the assembler would complain
instead of silently discarding the symbol.

zw

Re: making aliases into the middle of a structure

[Richard Henderson]

On Fri, Apr 23, 1999 at 01:40:34PM -0400, Zack Weinberg wrote:
> int common;
> extern int alias __attribute__ ((alias("common")));
> 
> `alias' will not be defined in the object file.  The assembly dump
> looks correct to me.

This is not a bug.  This is impossible to represent 
in the object file.  I believe SOM can do it if you
feel like hurting yourself...  ;-)


r~

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 00:14:34 -0600, Jeffrey A Law wrote:
>
>  In message < org15s33hj.fsf@lua.lbi.dcc.unicamp.br >you write:
>  > > Because the preprocessor can't compute offsetof() all the way down;
>  > > I'd have to compile and run a test program.  Which loses when
>  > > cross-compiling.
>  > 
>  > Well, you could try to extract this information from the assembly
>  > code, or from some RTL dump (since you're bound to gcc anyway), but I
>  > wouldn't like to be the one to implement it :-)
>Cygnus implemented a switch to have the compiler dump offsets for fields
>within structures in a format intended to be used by assembly code.
>
>It's not something we've used a lot and haven't ever thought it worth
>the effort to clean it up and submit it to egcs.

This is a cute idea, and I could think of uses in libc, but it doesn't
really solve my current problem (without excessive magic).  I'd much
rather be able to write

extern int var __attribute__ ((alias (structure.field)));

which is what the patch I sent yesterday implements.

Incidentally, I found what I think is a GAS bug: it forgets
aliases to symbols allocated with .comm.  For example:

int common;
extern int alias __attribute__ ((alias("common")));

`alias' will not be defined in the object file.  The assembly dump
looks correct to me.

zw

Re: making aliases into the middle of a structure

[Jamie Lokier]

Jeffrey A Law wrote:
> Cygnus implemented a switch to have the compiler dump offsets for fields
> within structures in a format intended to be used by assembly code.

Hey, my neuron flickered!

Does the dump include enough type information to generate a decent
non-conservative garbage collector?

-- Jamie

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 22:32:36 +0200, Jamie Lokier wrote:
>Jeffrey A Law wrote:
>> Cygnus implemented a switch to have the compiler dump offsets for fields
>> within structures in a format intended to be used by assembly code.
>
>Hey, my neuron flickered!
>
>Does the dump include enough type information to generate a decent
>non-conservative garbage collector?

You'd need stack frame information too, wouldn't you?

zw

Re: making aliases into the middle of a structure

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Zack Weinberg wrote:
> >Does the dump include enough type information to generate a decent
> >non-conservative garbage collector?
> 
> You'd need stack frame information too, wouldn't you?

In general yes, but a typed garbage collector that doesn't know about
stack frames would still be very useful.

Of course in my real fantasy it does do stack frames (based on PC à la
exceptions), it moves objects when that is more efficient, and it
efficiently handles polymorphic structures.  But that's fantasy land :-)

-- Jamie

Re: making aliases into the middle of a structure

[Jamie Lokier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Zack Weinberg wrote:
> >Does the dump include enough type information to generate a decent
> >non-conservative garbage collector?
> 
> You'd need stack frame information too, wouldn't you?

In general yes, but a typed garbage collector that doesn't know about
stack frames would still be very useful.

Of course in my real fantasy it does do stack frames (based on PC à la
exceptions), it moves objects when that is more efficient, and it
efficiently handles polymorphic structures.  But that's fantasy land :-)

-- Jamie

Re: making aliases into the middle of a structure

[Andi Kleen]

zack@rabi.columbia.edu (Zack Weinberg) writes:

> On Fri, 23 Apr 1999 22:32:36 +0200, Jamie Lokier wrote:
> >Jeffrey A Law wrote:
> >> Cygnus implemented a switch to have the compiler dump offsets for fields
> >> within structures in a format intended to be used by assembly code.
> >
> >Hey, my neuron flickered!
> >
> >Does the dump include enough type information to generate a decent
> >non-conservative garbage collector?
> 
> You'd need stack frame information too, wouldn't you?

Can't you extract that information from the dwarf2 exception unwinding tables?


-Andi


PS: I was a bit disappointed that -g -gdwarf2 -fomit-frame-pointer debugging 
still does not work with gdb 4.18 (although objdump shows that the executable
contains lots of frame description)

-- 
This is like TV. I don't like TV.

Re: making aliases into the middle of a structure

[Andi Kleen]

zack@rabi.columbia.edu (Zack Weinberg) writes:

> On Fri, 23 Apr 1999 22:32:36 +0200, Jamie Lokier wrote:
> >Jeffrey A Law wrote:
> >> Cygnus implemented a switch to have the compiler dump offsets for fields
> >> within structures in a format intended to be used by assembly code.
> >
> >Hey, my neuron flickered!
> >
> >Does the dump include enough type information to generate a decent
> >non-conservative garbage collector?
> 
> You'd need stack frame information too, wouldn't you?

Can't you extract that information from the dwarf2 exception unwinding tables?


-Andi


PS: I was a bit disappointed that -g -gdwarf2 -fomit-frame-pointer debugging 
still does not work with gdb 4.18 (although objdump shows that the executable
contains lots of frame description)

-- 
This is like TV. I don't like TV.

Re: making aliases into the middle of a structure

[Zack Weinberg]

On Fri, 23 Apr 1999 22:32:36 +0200, Jamie Lokier wrote:
>Jeffrey A Law wrote:
>> Cygnus implemented a switch to have the compiler dump offsets for fields
>> within structures in a format intended to be used by assembly code.
>
>Hey, my neuron flickered!
>
>Does the dump include enough type information to generate a decent
>non-conservative garbage collector?

You'd need stack frame information too, wouldn't you?

zw

Re: making aliases into the middle of a structure

[Jeffrey A Law]

  In message < 19990423223236.A5686@pcep-jamie.cern.ch >you write:
  > Jeffrey A Law wrote:
  > > Cygnus implemented a switch to have the compiler dump offsets for fields
  > > within structures in a format intended to be used by assembly code.
  > 
  > Hey, my neuron flickered!
  > 
  > Does the dump include enough type information to generate a decent
  > non-conservative garbage collector?
I don't believe so (it's been a couple years since we did that work).

If I remember correctly it just spit out name/offset information, not true
type information.

You could get true type information out of debug symbols though.  We did this
when I was at the UofU to implement link time parameter type checking across
modules.    It wasn't fun though :-)

jeff

Re: making aliases into the middle of a structure

[Jeffrey A Law]

  In message < 19990423223236.A5686@pcep-jamie.cern.ch >you write:
  > Jeffrey A Law wrote:
  > > Cygnus implemented a switch to have the compiler dump offsets for fields
  > > within structures in a format intended to be used by assembly code.
  > 
  > Hey, my neuron flickered!
  > 
  > Does the dump include enough type information to generate a decent
  > non-conservative garbage collector?
I don't believe so (it's been a couple years since we did that work).

If I remember correctly it just spit out name/offset information, not true
type information.

You could get true type information out of debug symbols though.  We did this
when I was at the UofU to implement link time parameter type checking across
modules.    It wasn't fun though :-)

jeff

Re: making aliases into the middle of a structure

[Jamie Lokier]

Jeffrey A Law wrote:
> Cygnus implemented a switch to have the compiler dump offsets for fields
> within structures in a format intended to be used by assembly code.

Hey, my neuron flickered!

Does the dump include enough type information to generate a decent
non-conservative garbage collector?

-- Jamie

Re: making aliases into the middle of a structure

[Jeffrey A Law]

  In message < org15s33hj.fsf@lua.lbi.dcc.unicamp.br >you write:
  > > Because the preprocessor can't compute offsetof() all the way down;
  > > I'd have to compile and run a test program.  Which loses when
  > > cross-compiling.
  > 
  > Well, you could try to extract this information from the assembly
  > code, or from some RTL dump (since you're bound to gcc anyway), but I
  > wouldn't like to be the one to implement it :-)
Cygnus implemented a switch to have the compiler dump offsets for fields
within structures in a format intended to be used by assembly code.

It's not something we've used a lot and haven't ever thought it worth
the effort to clean it up and submit it to egcs.

I've been kicking around the idea of using that code to build a testsuite
to look for unexpected changes in structure layouts between releases as
one component of a wider1 ABI compatibility testing plan.

Ie, we build a repository of tests which define a bunch of structs, unions,
classes.  We compile those tests with the magic option which records the
offset for each field within the structure.  We do this for each target we
care about.

Then we can compile a later release and compare the offsets for that target
to ensure they have not changed.

It's not a perfect solution for ABI testing, but it's a small step we can
use as a building block.  Will it actually happen -- I don't know.  It's
still a blue sky project.

Jeff

Re: making aliases into the middle of a structure

[Alexandre Oliva]

On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:

> On 22 Apr 1999 15:24:46 -0300, Alexandre Oliva wrote:
>> On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>> 
>>> extern __typeof(x.b) y __attribute__ ((alias("x.b")));
>> 
>> This can't work.  The alias attribute defines an alias to a *symbol*,
>> not to an arbitrary expression. 

> I don't see that it would be terribly hard to extend alias so it could
> handle SYMBOL_REFs and COMPONENT_REFs as well as strings.

That would probably be a good idea.  alias could accept an arbitrary
expression.  If it's an lvalue within a global symbol, it will define
an actual alias, otherwise it could just emit an error or ``construct
a temporary and bind the reference to it'', to put it in C++ terms :-) 

>> why don't you compute the offset, say, in the configure
>> script, then #define the appropriate alias string?

> Because the preprocessor can't compute offsetof() all the way down;
> I'd have to compile and run a test program.  Which loses when
> cross-compiling.

Well, you could try to extract this information from the assembly
code, or from some RTL dump (since you're bound to gcc anyway), but I
wouldn't like to be the one to implement it :-)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: making aliases into the middle of a structure

[Zack Weinberg]

On 22 Apr 1999 15:24:46 -0300, Alexandre Oliva wrote:
>On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:
>
>> extern __typeof(x.b) y __attribute__ ((alias("x.b")));
>
>This can't work.  The alias attribute defines an alias to a *symbol*,
>not to an arbitrary expression. 

I don't see that it would be terribly hard to extend alias so it could
handle SYMBOL_REFs and COMPONENT_REFs as well as strings.

>Since you may have to get quite
>platform-specific because of the potential need for leading
>underscores, 

This is already handled in the real framework; the above was a
stripped down example.

>why don't you compute the offset, say, in the configure
>script, then #define the appropriate alias string?

Because the preprocessor can't compute offsetof() all the way down;
I'd have to compile and run a test program.  Which loses when
cross-compiling.

zw

Re: making aliases into the middle of a structure

[Alexandre Oliva]

On Apr 22, 1999, Zack Weinberg <zack@rabi.columbia.edu> wrote:

> extern __typeof(x.b) y __attribute__ ((alias("x.b")));

This can't work.  The alias attribute defines an alias to a *symbol*,
not to an arbitrary expression.  Since you may have to get quite
platform-specific because of the potential need for leading
underscores, why don't you compute the offset, say, in the configure
script, then #define the appropriate alias string?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

making aliases into the middle of a structure

[Zack Weinberg]

Consider this bit of code.

struct s
{
  int a, b;
};

struct s x = { 0, 0 };

extern __typeof(x.b) y __attribute__ ((alias("x.b")));

The goal is to have x.b and y refer to the same memory location.  I am
aware that this is somewhat perverse, but there are legitimate reasons
(binary compatibility) for it.

If gcc were to translate this into

.data
.globl x
        .align 4
        .type    x,@object
        .size    x,8
x:
        .zero   8
.globl y
        .set    y, x+4

then the assembler would generate a correct object module, and
references to `x.b' and `y' would indeed operate on the same memory
location.

Unfortunately this is not what gcc produces; instead I get

.data
.globl x
        .align 4
        .type    x,@object
        .size    x,8
x:
        .zero   8
.globl y
        .set    y,x.b


The assembler generates an undefined reference to the symbol `x.b' and
forgets about `y'.

I have experimented with workarounds involving offsetof();
unfortunately, the best this can do is

	.set y,x + ((size_t) &((s *)0)->b)

which is not an expression that the assembler can evaluate.  I do not
want to write a raw assembly module, because that will break if the
padding inside the structure, or the sizes of the component types,
change.

Any suggestions?

zw