From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AD8DD385840F; Thu, 2 May 2024 12:55:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD8DD385840F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1714654550; bh=anMb6Vvwi33O1rNRI5rldA146EoOyrRc+P6e0+S0Z8I=; h=From:To:Subject:Date:From; b=wcYftIm/jxpydMxOCjtMqcHZGqVKck+7ZVEqn/cPvJp+Mh17t6TXHN+RFQPElJNvO JTLHsImMWjGz76gU6Pp0PHiXTuQ5ynwvzZAiq3YS73qxPzt5CepIhw+ED8a6w3R1pO 0t6kDQBcTjQNr6cb2U6yPsLLhVMY24i4voqdhr1s= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug exp/31693] New: [gdb/exp] cast not handled correctly by indirection Date: Thu, 02 May 2024 12:55:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: exp X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31693 Bug ID: 31693 Summary: [gdb/exp] cast not handled correctly by indirection Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: exp Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- I was reviewing this patch ( https://sourceware.org/pipermail/gdb-patches/2024-May/208737.html ) and came across this description: ... + # On Linux, using -g3, which causes macro information to + # be included in the debuginfo, errno might be defined as + # follows: + # + # #define errno (*__errno_location ()) + # + # So, when we do "ptype errno", due to macro expansion, + # this ends up being "ptype (*__errno_location ())". So + # the call to __errno_location (or something similar on + # other OSes) is the call mentioned in the error message. + # + # For the test "print (int) errno", we're casting the + # result of the expression, which includes both the call + # along with a dereferencing operation. + # + # This will sometimes produce the right answer, but it's + # also just as likely to fail. E.g. on x86_64, if the + # address being returned as a 32-bit int is the same as + # that which would have been returned as a 64-bit pointer, + # then the test might pass. Otherwise, it will almost + # certainly fail, which is why we XFAIL it here. But do + # expect to see the occasional XPASS for this case. ... I tried to reproduce this (in a fedora rawhide container with the check-errno-macros exec) and got: ... (gdb) p errno '__errno_location' has unknown return type; cast the call to its declared return type (gdb) ptype errno '__errno_location' has unknown return type; cast the call to its declared return type (gdb) p __errno_location $9 =3D {} 0x7ffff7d10540 <__errno_location> (gdb) ptype __errno_location type =3D () (gdb) p __errno_location () '__errno_location' has unknown return type; cast the call to its declared return type (gdb) p *__errno_location () '__errno_location' has unknown return type; cast the call to its declared return type (gdb) p (*__errno_location ()) '__errno_location' has unknown return type; cast the call to its declared return type (gdb) p (int)(*__errno_location ()) Cannot access memory at address 0xfffffffff7ce36c8 (gdb) p (int)(*(int *)__errno_location ()) $10 =3D 42 (gdb) p /x &(int)*__errno_location () $11 =3D 0xfffffffff7ce36c8 (gdb) p /x &(int)*(int *)__errno_location () $12 =3D 0x7ffff7ce36c8 (gdb) p /x &(int)*(int)__errno_location () $3 =3D 0xfffffffff7ce36c8 ... We known that __errno_location has an unknown return type. We ask for it t= o be cast before using it. But then when using it nested in a expression we cas= t it to int. Probably there's a bug in this code expop.h at unop_ind_base_operation: ... value *evaluate (struct type *expect_type, struct expression *exp, enum noside noside) override { if (expect_type !=3D nullptr && expect_type->code () =3D=3D TYPE_CODE_P= TR) expect_type =3D check_typedef (expect_type)->target_type (); value *val =3D std::get<0> (m_storage)->evaluate (expect_type, exp, nos= ide); return eval_op_ind (expect_type, exp, noside, val); } ... We enter with expect_type "int", we should we execute the call with expect_= type "int*", but instead we do so with "int". --=20 You are receiving this mail because: You are on the CC list for the bug.=