[RFA,2/6] Handle alignof and _Alignof

  This adds alignof and _Alignof to the C/C++ expression parser, and
adds new tests to test the features.  The tests are written to try to
ensure that gdb's knowledge of alignment rules stays in sync with the
compiler's.

2018-04-24  Tom Tromey  <tom@tromey.com>

	PR exp/17095:
	* NEWS: Update.
	* std-operator.def (UNOP_ALIGNOF): New operator.
	* expprint.c (dump_subexp_body_standard) <case UNOP_ALIGNOF>:
	New.
	* eval.c (evaluate_subexp_standard) <case UNOP_ALIGNOF>: New.
	* c-lang.c (c_op_print_tab): Add alignof.
	* c-exp.y (ALIGNOF): New token.
	(exp): Add "ALIGNOF" production.
	(ident_tokens): Add _Alignof and alignof.

2018-04-24  Tom Tromey  <tom@tromey.com>

	PR exp/17095:
	* gdb.dwarf2/dw2-align.exp: New file.
	* gdb.cp/align.exp: New file.
	* gdb.base/align.exp: New file.
---
 gdb/ChangeLog                          |  13 ++++
 gdb/NEWS                               |   3 +
 gdb/c-exp.y                            |   8 +-
 gdb/c-lang.c                           |   1 +
 gdb/eval.c                             |  13 ++++
 gdb/expprint.c                         |   1 +
 gdb/std-operator.def                   |   1 +
 gdb/testsuite/ChangeLog                |   7 ++
 gdb/testsuite/gdb.base/align.exp       |  94 ++++++++++++++++++++++++
 gdb/testsuite/gdb.cp/align.exp         | 129 +++++++++++++++++++++++++++++++++
 gdb/testsuite/gdb.dwarf2/dw2-align.exp |  83 +++++++++++++++++++++
 11 files changed, 352 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.base/align.exp
 create mode 100644 gdb/testsuite/gdb.cp/align.exp
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-align.exp
  

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>
> Date: Tue, 24 Apr 2018 09:22:18 -0600
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index 63fe30d175..6631b53475 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -9,6 +9,9 @@
>  * 'info proc' now works on running processes on FreeBSD systems and core
>    files created on FreeBSD systems.
>  
> +* C expressions can now use _Alignof, and C++ expressions can now use
> +  alignof.
> +
>  * New commands

OK for this part.

Thanks.
  

Hi Tom,

What's in the patch looks good to me.  I have comments on the
tests -- I think it'd be good to extend them a bit more.

On 04/24/2018 04:22 PM, Tom Tromey wrote:

> +
> +# The types we're going to test.
> +
> +set typelist {
> +    char {unsigned char}
> +    short {unsigned short}
> +    int {unsigned int}
> +    long {unsigned long}
> +    {long long} {unsigned long long}
> +    float
> +    double

Shouldn't we test "long double"?  Patch #1 handles it.
Not sure all GCC ports support it, may require separate compilation.

Also, I'm wondering about "__int128" if the target
supports it.

In C++, do we get the alignment of non-standard layout classes right?
E.g., structs with references.  And structs with virtual methods, like:

 struct S
 {
   virtual ~S ();
   char c;
 };

This should print 8 instead of 1 on x86-64, due to the vtable pointer.

I think it'd be good to cover those things in the tests too.

Likewise arrays, bitfields and typedefs?

I didn't spot any test for the
 "could not determine alignment of type"
case to make that that works gracefully without crashing.  

What do we do with _Alignof(void)?  We treat sizeof(void) == 1,
like gcc, so I assume the _Alignof will return 1 too instead
of erroring out.

Finally, for completeness, GCC allows _Alignof applied to
expressions, so I guess we should to.  Does the series allow that?
I.e., can we do _Alignof(1 + 1)?  Does the parser handle that?

Shouldn't we test _Alignof applied to the structure fields too?

There was a snippet in the patch that made me wonder if the patch
handles alignof of a no-debug-info variable and and the return-type
of a no-debug-info function correctly (instead of e.g., crashing).
I'd be nice to add a couples test to gdb.base/nodebug.exp
to make sure.  E.g.:
   p _Alignof (dataglobal64_1)
   p _Alignof (middle())"

Also, please add intro comments to the testcase .exp files, so
that later on people can find out what the testcase is
about easily.

Thanks,
Pedro Alves
  

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> Shouldn't we test "long double"?  Patch #1 handles it.
Pedro> Not sure all GCC ports support it, may require separate compilation.

I thought C didn't have long double (it's tested in the C++ test), but I
see it does.  I will add that.

Pedro> Also, I'm wondering about "__int128" if the target
Pedro> supports it.

I have bad feelings about trying to detect this in the test.

Pedro> In C++, do we get the alignment of non-standard layout classes right?
Pedro> Likewise arrays, bitfields and typedefs?
Pedro> What do we do with _Alignof(void)?

I will add these.

Pedro> I didn't spot any test for the
Pedro>  "could not determine alignment of type"
Pedro> case to make that that works gracefully without crashing.  

I think this one is maybe hard to test without some kind of bug (so far
I've only seen it when some part of the patch was buggy), but I will see
what I can do.

Pedro> Finally, for completeness, GCC allows _Alignof applied to
Pedro> expressions, so I guess we should to.  Does the series allow that?
Pedro> I.e., can we do _Alignof(1 + 1)?  Does the parser handle that?

No, and this is hard to do.  I've left the door open a bit by the way
the new expression emits a new OP instead of simply writing out a
constant (and this allows alignof(typeof(..)) to work as well).
However, I think the way the parser is written makes this difficult,
which is one reason that sizeof requires or does not require parens
depending on whether the argument is an expression or a type.

It would be possible to write "alignof expression", but I didn't want to
add an extension, especially since "alignof(typeof(expression))" is
pretty easy.

Pedro> Shouldn't we test _Alignof applied to the structure fields too?

It seems to me that this would necessarily be an expression, not a type.

Pedro> There was a snippet in the patch that made me wonder if the patch
Pedro> handles alignof of a no-debug-info variable and and the return-type
Pedro> of a no-debug-info function correctly (instead of e.g., crashing).
Pedro> I'd be nice to add a couples test to gdb.base/nodebug.exp
Pedro> to make sure.  E.g.:
Pedro>    p _Alignof (dataglobal64_1)
Pedro>    p _Alignof (middle())"

Pedro> Also, please add intro comments to the testcase .exp files, so
Pedro> that later on people can find out what the testcase is
Pedro> about easily.

Ok to all.

Tom
  

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> What do we do with _Alignof(void)?  We treat sizeof(void) == 1,
Pedro> like gcc, so I assume the _Alignof will return 1 too instead
Pedro> of erroring out.

_Alignof(void) is accepted by gcc but alignof(void) is rejected by g++.
I've made the test do the former.

Tom
  

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> There was a snippet in the patch that made me wonder if the patch
Pedro> handles alignof of a no-debug-info variable and and the return-type
Pedro> of a no-debug-info function correctly (instead of e.g., crashing).
Pedro> I'd be nice to add a couples test to gdb.base/nodebug.exp
Pedro> to make sure.  E.g.:
Pedro>    p _Alignof (dataglobal64_1)
Pedro>    p _Alignof (middle())"

I think these can't be done because _Alignof only applies to types.

Tom
  

On 04/24/2018 09:23 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> Shouldn't we test "long double"?  Patch #1 handles it.
> Pedro> Not sure all GCC ports support it, may require separate compilation.
> 
> I thought C didn't have long double (it's tested in the C++ test), but I
> see it does.  I will add that.
> 
> Pedro> Also, I'm wondering about "__int128" if the target
> Pedro> supports it.
> 
> I have bad feelings about trying to detect this in the test.

My thought was to simply support compiling a separate testcase
binary for a given type instead of mixing all types in
the same program.  So if a type is not supported, the program
won't compile and we'd skip the testing that type.  It'd basically
require moving the body of the testing code to a procedure that
is passed a list of types to compile & test in group.  So the
basic types that must be supported by all C/C++ implementations
would be one single group.  While other types like __int128 and
any other we add in future would be in separate groups / passes.

> 
> Pedro> In C++, do we get the alignment of non-standard layout classes right?
> Pedro> Likewise arrays, bitfields and typedefs?
> Pedro> What do we do with _Alignof(void)?
> 
> I will add these.
> 
> Pedro> I didn't spot any test for the
> Pedro>  "could not determine alignment of type"
> Pedro> case to make that that works gracefully without crashing.  
> 
> I think this one is maybe hard to test without some kind of bug (so far
> I've only seen it when some part of the patch was buggy), but I will see
> what I can do.
> 
> Pedro> Finally, for completeness, GCC allows _Alignof applied to
> Pedro> expressions, so I guess we should to.  Does the series allow that?
> Pedro> I.e., can we do _Alignof(1 + 1)?  Does the parser handle that?
> 
> No, and this is hard to do.  I've left the door open a bit by the way
> the new expression emits a new OP instead of simply writing out a
> constant (and this allows alignof(typeof(..)) to work as well).
> However, I think the way the parser is written makes this difficult,

OOC, can you expand a bit on what you mean here?  I would have assumed
that at the parser level, we'd just copy exactly what is done for
supporting expressions with sizeof.

> which is one reason that sizeof requires or does not require parens
> depending on whether the argument is an expression or a type.

Not clear what you mean here.  I know that sizeof with an expression
requires parenthesis in C/C++, but I'm not connecting the dots with
the above comments.

> It would be possible to write "alignof expression", but I didn't want to
> add an extension, 

Oh, you mean, you would want to make gdb require the parens when
given an expression as prerequisite for supporting expressions?

I wouldn't think that as a blocker, since AFAICS, we already have
that "extension" for sizeof:

 (gdb) p sizeof 1 + 1
 $1 = 5

so I wouldn't see it as a problem to make alignof work the same way,
and then if/when somebody wants to make gdb require the parens,
he'd just do it to both sizeof/alignof.

Anyway, I'll take alignof/_Alignof with no expressions over
no alignof/_Alignof, for sure.  :-)

> especially since "alignof(typeof(expression))" is
> pretty easy.

Ah, if that works, then yeah, that's a good escape hatch.

Should we have a test for that?

> 
> Pedro> Shouldn't we test _Alignof applied to the structure fields too?
> 
> It seems to me that this would necessarily be an expression, not a type.

Yeah.  I think the main complication here would be related to how the
expression machinery returns values and types, and then how to
distinguish a struct field of type X with a standalone variable of
type X, for alignof purposes (given x86's funny alignments).

Thanks,
Pedro Alves
  

On 04/26/2018 09:45 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> What do we do with _Alignof(void)?  We treat sizeof(void) == 1,
> Pedro> like gcc, so I assume the _Alignof will return 1 too instead
> Pedro> of erroring out.
> 
> _Alignof(void) is accepted by gcc but alignof(void) is rejected by g++.
> I've made the test do the former.

It's a warning, not rejected.  Just like for sizeof(void).

Thanks,
Pedro Alves
  

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> My thought was to simply support compiling a separate testcase
Pedro> binary for a given type instead of mixing all types in
Pedro> the same program.  So if a type is not supported, the program
Pedro> won't compile and we'd skip the testing that type.

Ok, I can do that.  I'll put the "void" test there too -- the problem
with it being that (1) we'd need "nowarnings" and (2) since it isn't
really valid, presumably some other C++ compiler might reject it.

Tom> No, and this is hard to do.  I've left the door open a bit by the way
Tom> the new expression emits a new OP instead of simply writing out a
Tom> constant (and this allows alignof(typeof(..)) to work as well).
Tom> However, I think the way the parser is written makes this difficult,

Pedro> OOC, can you expand a bit on what you mean here?  I would have assumed
Pedro> that at the parser level, we'd just copy exactly what is done for
Pedro> supporting expressions with sizeof.

Right now we have:

exp	:	ALIGNOF '(' type_exp ')'	%prec UNARY
			{ write_exp_elt_opcode (pstate, UNOP_ALIGNOF); }
	;


We could add another production like:

exp : ALIGNOF '(' exp ')' ...

... but when I tried this the resulting parser had issues with the tests
-- claiming syntax errors where there were none.

Tom> which is one reason that sizeof requires or does not require parens
Tom> depending on whether the argument is an expression or a type.

Pedro> Not clear what you mean here.  I know that sizeof with an expression
Pedro> requires parenthesis in C/C++, but I'm not connecting the dots with
Pedro> the above comments.

For sizeof there are two productions:

exp	:	SIZEOF exp       %prec UNARY
			{ write_exp_elt_opcode (pstate, UNOP_SIZEOF); }
	;

exp	:	SIZEOF '(' type ')'	%prec UNARY


I don't really know offhand why the latter is taken when a paren is
seen, it seems ambiguous to me.

Debugging this stuff is not very easy or enjoyable.  Switching to a
recursive descent parser would eliminate problems like this, because
some of the decisions would be turned into more simple programming
problems.

Tom> especially since "alignof(typeof(expression))" is
Tom> pretty easy.

Pedro> Ah, if that works, then yeah, that's a good escape hatch.

Pedro> Should we have a test for that?

Yeah, I'll add one.

Pedro> Yeah.  I think the main complication here would be related to how the
Pedro> expression machinery returns values and types, and then how to
Pedro> distinguish a struct field of type X with a standalone variable of
Pedro> type X, for alignof purposes (given x86's funny alignments).

I think with the new agreed-upon definition of alignof, this is no
longer a concern.

Tom
  

Pedro> My thought was to simply support compiling a separate testcase
Pedro> binary for a given type instead of mixing all types in
Pedro> the same program.

I ended up just adding a gdb_caching_proc that detects __int128 and then
conditionally appending __int128 to the list of types.  This seemed
simpler, and also it seemed to me that the test should have a lot of
type mixing anyway.

Tom