From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic302-20.consmr.mail.ir2.yahoo.com (sonic302-20.consmr.mail.ir2.yahoo.com [87.248.110.83]) by sourceware.org (Postfix) with ESMTPS id B8E3B388E831 for ; Tue, 5 May 2020 13:33:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B8E3B388E831 X-YMail-OSG: AV7hvvsVM1mSk_XLOKbFSMVj4Xn81Cv6DIquOy_Spkcd6l0J64M1zeUvtCQ0.b8 2dNmP5zZ4D.oTVvZcvAqJppbMmCOkfI6PsbDIWiXwg9_OVXpCn65_8LWAF0o0yWONOoGnNIeNHLW rGtHxLCv4HNcFEr.15hsz0IB2d15Jpgj3DcjBpmrcNyosumdvKN4apfzX0aXfx0jfc8ZfNxMRTU8 wfc3R7DfEpk7eUwgPBsEQWR7tNQ85vtTuFdyDQBEoRr3hThpoV6UHF5ho1vhxXRd3BBHJORv2VPh Rb9mY0yOFNDre8yU44swGAjmrca9QAJSn4juavdPmI6htsP52VEFNJmZOsYzwBiRBQFrJoZ3KTHN 5u2jMtmNG74hZI5GVWKxx76UXVVzdbxHMJ4HXsgeOcUlcSEmeQMb6x2clYw3cP.93WLrsRUAcyir ZuOO.OIKlWZeDj3x1V6exPhdbci31LNF5X7ksu_Y2_QbJ8F1znYVPDDY_fCZvEtaUPNim.H5fznz g8Y.A3GccYE9ST_IDggSK1cTeW1gCFuim0cRcWCr46HKuCuhmzfodS3niQGe4pipg.vlbfMUvfbj 3hLVeT8lVg7E0LRKbJ781Zq5PBdTDmFiym4Ek3roRJerMkXbF57XapefwoZ7AYlbn1wDeLteBN6e d0ePP.p4wDtCYcbwW0sfjP4skdy0nPHJZ4wOED6UZI_k.9XVrnw_Y3bGC6M8EqviFttsw7pp._lJ BqPanksN89xfv7epdW.g4MruN5FUQomWGTcwjN.ESevCCTnZqLEgt9sosMzGtFwezWMKw2jlFiGM 7W02zwNgzhjdcezVu9hgDCqMmCel7mTXuxJu_a7Brxp29kFQlI_abGHmBdzqaFs.FjFic5TD8lIG NoUGWox0hnQEFoTWt9DX.lF8URIGa9wp5l2ssRIAk7G0VkWiAdS153c319rByuF_4dBgvSE8pHUv am1XToIAAmwqFWdXIMY4d7sAIEey6bhupEO444PILRpazyoEHcamwk5T_klzN3Gdmc1C1WhULJgT zS_JAyI9LEKPzXypV3_.xNhDh93GSbKT.OeViFW8kqAVBkOwuWIwhZ9hgCz1ZEoGWrrnVKPm.v5E a6oFfmk.CQKrIwBCHUerCa4af035H59Rbu4x9chUn2GDSsBh7hqyySQ7cClpzR7MruiQoz.VHJD4 T5eKF8elLUpdn9jasPecEvFyTo_PGReY.RprheuYgh4yeJSCGWrJ2Du9ANVN7aFCxbnQFAaBZhiV 8Od.cAQAc3R80D9CnIgilLwGyUjDRpTzGc6J9sK5lFIpWvzvA9jxzGsp.yk85_2zLtObIYwQbF02 rU5iZnJ8FzFZpoCZG2pH17fnYGnx6.k51ggMgZxJBLbRAnOW.HBCRdj3VrdqlyNGBZth86DTS06w Bhyic1JlSqwTsP87GLq_UHVR3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ir2.yahoo.com with HTTP; Tue, 5 May 2020 13:33:15 +0000 Received: by smtp417.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 68afe6c812283ea71bda3aae009685a7; Tue, 05 May 2020 13:33:14 +0000 (UTC) From: Hannes Domani To: gdb-patches@sourceware.org Subject: [RFC][PATCH] Fix function argument and return value locations Date: Tue, 5 May 2020 15:32:56 +0200 Message-Id: <20200505133256.4790-1-ssbssa@yahoo.de> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 200503-0, 05/03/2020), Outbound message X-Antivirus-Status: Clean References: <20200505133256.4790-1-ssbssa.ref@yahoo.de> X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 13:33:27 -0000 I'm investigating some testsuite failures on Windows, here it's about gdb.base/call-sc.exp and gdb.base/callfuncs.exp. Also, this is not a finished patch, because some things I found out were surprising for me. For the function arguments, I only had these failures: FAIL: gdb.base/callfuncs.exp: p t_float_complex_values(fc1, fc2) FAIL: gdb.base/callfuncs.exp: p t_float_complex_many_args(fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4) These were fixed by adding TYPE_CODE_COMPLEX to the types passed via XMM registers. For return values, there were a lot more issues: - TYPE_CODE_DECFLOAT is NOT returned via XMM0. - long double is NOT returned via XMM0. - but __int128 IS returned via XMM0. - the comments for TYPE_CODE_FLT state that __m128, __m128i and __m128d are returned by XMM0, and this is correct, but it doesn't actually check for them, because they are TYPE_CODE_ARRAY with TYPE_VECTOR Could it be that this depends on the version of the used compiler? Also, in call-sc.exp, for the "value foo returned" test, I'm wondering if it can really ever return 90. If any of this correct, then I will send a proper patch again (and maybe I should split the argument part into its own patch), if not, please advise. --- gdb/amd64-windows-tdep.c | 23 ++++++++++++++++++----- gdb/testsuite/gdb.base/call-sc.c | 3 ++- gdb/testsuite/gdb.base/call-sc.exp | 13 +++++++++++++ gdb/testsuite/gdb.base/callfuncs.exp | 4 ++++ 4 files changed, 37 insertions(+), 6 deletions(-) diff --git a/gdb/amd64-windows-tdep.c b/gdb/amd64-windows-tdep.c index 740152b7de..1f9b868562 100644 --- a/gdb/amd64-windows-tdep.c +++ b/gdb/amd64-windows-tdep.c @@ -77,7 +77,8 @@ static int amd64_windows_passed_by_xmm_register (struct type *type) { return ((TYPE_CODE (type) == TYPE_CODE_FLT - || TYPE_CODE (type) == TYPE_CODE_DECFLOAT) + || TYPE_CODE (type) == TYPE_CODE_DECFLOAT + || TYPE_CODE (type) == TYPE_CODE_COMPLEX) && (TYPE_LENGTH (type) == 4 || TYPE_LENGTH (type) == 8)); } @@ -299,17 +300,29 @@ amd64_windows_return_value (struct gdbarch *gdbarch, struct value *function, switch (TYPE_CODE (type)) { case TYPE_CODE_FLT: - case TYPE_CODE_DECFLOAT: - /* __m128, __m128i, __m128d, floats, and doubles are returned - via XMM0. */ - if (len == 4 || len == 8 || len == 16) + /* floats, and doubles are returned via XMM0. */ + if (len == 4 || len == 8) regnum = AMD64_XMM0_REGNUM; break; + case TYPE_CODE_ARRAY: + /* __m128, __m128i and __m128d are returned via XMM0. */ + if (TYPE_VECTOR (type) && len == 16) + { + enum type_code code = TYPE_CODE (TYPE_TARGET_TYPE (type)); + if (code == TYPE_CODE_INT || code == TYPE_CODE_FLT) + { + regnum = AMD64_XMM0_REGNUM; + break; + } + } + /* fall through */ default: /* All other values that are 1, 2, 4 or 8 bytes long are returned via RAX. */ if (len == 1 || len == 2 || len == 4 || len == 8) regnum = AMD64_RAX_REGNUM; + else if (len == 16 && TYPE_CODE (type) == TYPE_CODE_INT) + regnum = AMD64_XMM0_REGNUM; break; } diff --git a/gdb/testsuite/gdb.base/call-sc.c b/gdb/testsuite/gdb.base/call-sc.c index ba80576ac3..c798426ec4 100644 --- a/gdb/testsuite/gdb.base/call-sc.c +++ b/gdb/testsuite/gdb.base/call-sc.c @@ -35,6 +35,7 @@ typedef t T; #endif T foo = '1', L; +T init = '9'; T fun() { @@ -55,7 +56,7 @@ int main() { int i; - Fun(foo); + Fun(init); /* An infinite loop that first clears all the variables and then calls the function. This "hack" is to make re-testing easier - diff --git a/gdb/testsuite/gdb.base/call-sc.exp b/gdb/testsuite/gdb.base/call-sc.exp index 719000435a..9697c5ac24 100644 --- a/gdb/testsuite/gdb.base/call-sc.exp +++ b/gdb/testsuite/gdb.base/call-sc.exp @@ -291,6 +291,19 @@ proc test_scalar_returns { } { fail "${test}" } } + -re " = 57 .*${gdb_prompt} $" { + if $return_value_unknown { + # The struct return case. + # The return value is stored on the stack, and since GDB + # didn't override it, it still has value that was stored + # there in the earlier Foo(init) call. + pass "${test}" + } else { + # This contradicts the above claim that GDB knew + # the location of the return-value. + fail "${test}" + } + } -re ".*${gdb_prompt} $" { if $return_value_unimplemented { # What a suprize. The architecture hasn't implemented diff --git a/gdb/testsuite/gdb.base/callfuncs.exp b/gdb/testsuite/gdb.base/callfuncs.exp index 642fe0d7fd..8c47f72dd9 100644 --- a/gdb/testsuite/gdb.base/callfuncs.exp +++ b/gdb/testsuite/gdb.base/callfuncs.exp @@ -542,6 +542,10 @@ if { ![prepare_for_testing "failed to prepare" $testfile $srcfile "$compile_flag perform_all_tests 1 } +# On Windows, you can't replace the executable if it is still running. +gdb_exit +gdb_start + if { ![prepare_for_testing "failed to prepare" $testfile $srcfile "$compile_flags additional_flags=-DNO_PROTOTYPES"] } { with_test_prefix "noproto" { perform_all_tests 0 -- 2.26.2