Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alan Hayward <Alan.Hayward@arm.com>
To: Pedro Alves <palves@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	nd <nd@arm.com>
Subject: Re: [PATCH 1/2] AArch64 AAPCS: Empty structs have non zero size in C++
Date: Fri, 18 Jan 2019 10:34:00 -0000	[thread overview]
Message-ID: <5255A57D-0F2C-4A3B-816A-6F46C0B0C2B1@arm.com> (raw)
In-Reply-To: <386a4a7f-f7df-e1da-42b8-b0724e1e36b2@redhat.com>

(Thanks, would have pushed, but outstanding question below)…


> On 17 Jan 2019, at 17:08, Pedro Alves <palves@redhat.com> wrote:
> 
> On 01/16/2019 03:57 PM, Alan Hayward wrote:
>> When gdb.base/infcall-nested-structs.c is complied as C++, the structs
>> containing empty structs are no longer passed via float arguments.
> 
> This reads a bit ambiguously.  Which is it?
> 
> #1 - No longer passed by GCC, but GDB still passes.
> #2 - No longer passed by GDB, but GCC still passes.
> 
>> This is because structs in C++ have a minimum size of 1.  This can then
>> cause padding in the struct, which is disallowed for AAPCS.
> 
> Does this "disallowed" mean that structs with padding are
> not allowed to be passed via float arguments?  Took me a while to
> grok that.
> 
> It'd be good to clarify the commit log.

I’ll change to:
When gdb.base/infcall-nested-structs.c is complied as C++, the compiler
will not pass structs containing empty structs via float arguments.
This is because structs in C++ have a minimum size of 1, causing padding
in the struct.  The AAPCS does not allow structs with padding to be
passed in float arguments.

>> +foreach l $lang {
>> +    set dir "$l"
>> +    remote_exec build "rm -rf [standard_output_file ${dir}]"
>> +    remote_exec build "mkdir -p [standard_output_file ${dir}]"
> 
> I think these should be
> 
>   remote_exec host
> 
> not "build" ?
> 
> For remote-host testing, where the compiler and debugger run on the
> host machine.
> 

This was due to copying from another test - I’ll raise a quick
patch to fix those up too.


> Could you please file a bug for the x86 internal errors, and
> kfail the test for x86?
> 

Will raise a bug.

The pattern for which tests pass and fail is not that simple.
Each structure gets tested 49 times on c++ (with different types).
Eg: For struct_01_01, 17 of them fail, but for struct_01_04 only
13 fail.

Is it ok to be over cautious (and have some XPASS results)
or do we really need a large messy if statement with all the
exact matches?


> Otherwise looks fine to me.
> 
> Thanks,
> Pedro Alves
> 
>> +}
>> +
>> +
>> set int_types { tc ts ti tl tll }
>> set float_types { tf td tld }
>> set complex_types { tfc tdc tldc }
>> @@ -44,7 +58,7 @@ proc I2A { n } {
>> # types of the struct fields within the source.  Run up to main.
>> # Also updates the global "testfile" to reflect the most recent build.
>> 
>> -proc start_nested_structs_test { types } {
>> +proc start_nested_structs_test { lang types } {
>>     global testfile
>>     global srcfile
>>     global binfile
>> @@ -53,9 +67,11 @@ proc start_nested_structs_test { types } {
>>     global compile_flags
>> 
>>     standard_testfile .c
>> +    set dir "$lang"
>> 
>>     # Create the additional flags
>>     set flags $compile_flags
>> +    lappend flags $lang
>> 
>>     for {set n 0} {$n<[llength ${types}]} {incr n} {
>> 	set m [I2A ${n}]
>> @@ -64,7 +80,7 @@ proc start_nested_structs_test { types } {
>> 	append testfile "-" "$t"
>>     }
>> 
>> -    set binfile [standard_output_file ${testfile}]
>> +    set binfile [standard_output_file ${dir}/${testfile}]
>>     if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable "${flags}"] != "" } {
>> 	unresolved "failed to compile"
>> 	return 0
>> @@ -125,48 +141,50 @@ proc run_tests {} {
>> # Set up a test prefix, compile the test binary, run to main, and then
>> # run some tests.
>> 
>> -proc start_gdb_and_run_tests { types } {
>> +proc start_gdb_and_run_tests { lang types } {
> 
>>     set prefix "types"
>> 
>>     foreach t $types {
>> 	append prefix "-" "${t}"
>>     }
>> 
>> -    with_test_prefix $prefix {
>> -	if { [start_nested_structs_test $types] } {
>> -	    run_tests
>> +    foreach_with_prefix l $lang {
>> +	with_test_prefix $prefix {
>> +	    if { [start_nested_structs_test $l $types] } {
>> +		run_tests
>> +	    }
>> 	}
>>     }
>> }
>> 
>> foreach ta $int_types {
>> -    start_gdb_and_run_tests $ta
>> +    start_gdb_and_run_tests $lang $ta
>> }
>> 
>> if [support_complex_tests] {
>>     foreach ta $complex_types {
>> -	start_gdb_and_run_tests $ta
>> +	start_gdb_and_run_tests $lang $ta
>>     }
>> }
>> 
>> if ![gdb_skip_float_test] {
>>     foreach ta $float_types {
>> -	start_gdb_and_run_tests $ta
>> +	start_gdb_and_run_tests $lang $ta
>>     }
>> 
>>     foreach ta $int_types {
>> 	foreach tb $float_types {
>> -	    start_gdb_and_run_tests [list $ta $tb]
>> +	    start_gdb_and_run_tests $lang [list $ta $tb]
>> 	}
>>     }
>> 
>>     foreach ta $float_types {
>> 	foreach tb $int_types {
>> -	    start_gdb_and_run_tests [list $ta $tb]
>> +	    start_gdb_and_run_tests $lang [list $ta $tb]
>> 	}
>> 
>> 	foreach tb $float_types {
>> -	    start_gdb_and_run_tests [list $ta $tb]
>> +	    start_gdb_and_run_tests $lang [list $ta $tb]
>> 	}
>>     }
>> }
>> 
> 


  reply	other threads:[~2019-01-18 10:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 15:57 [PATCH 0/2] AArch64 AAPCS: Improve argument passing Alan Hayward
2019-01-16 15:57 ` [PATCH 1/2] AArch64 AAPCS: Empty structs have non zero size in C++ Alan Hayward
2019-01-17 17:08   ` Pedro Alves
2019-01-18 10:34     ` Alan Hayward [this message]
2019-01-21 15:52       ` Alan Hayward
2019-10-10 23:49         ` Tom de Vries
2019-10-11 12:14           ` [gdb/tdep] Fix 'Unexpected register class' assert in amd64_push_arguments Tom de Vries
2019-10-14 13:10             ` Alan Hayward
2019-10-14 15:23               ` Tom de Vries
2019-01-16 15:57 ` [PATCH 2/2] AArch64 AAPCS: Ignore static members Alan Hayward
2019-01-17 17:22   ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5255A57D-0F2C-4A3B-816A-6F46C0B0C2B1@arm.com \
    --to=alan.hayward@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nd@arm.com \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox