[Bug exp/31693] New: [gdb/exp] cast not handled correctly by indirection

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31693

            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 = {<text variable, no debug info>} 0x7ffff7d10540 <__errno_location>
(gdb) ptype __errno_location
type = <unknown 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 (*__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 = 42
(gdb) p /x &(int)*__errno_location ()
$11 = 0xfffffffff7ce36c8
(gdb) p /x &(int)*(int *)__errno_location ()
$12 = 0x7ffff7ce36c8
(gdb) p /x &(int)*(int)__errno_location ()
$3 = 0xfffffffff7ce36c8
...

We known that __errno_location has an unknown return type.  We ask for it to be
cast before using it.  But then when using it nested in a expression we cast 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 != nullptr && expect_type->code () == TYPE_CODE_PTR)
      expect_type = check_typedef (expect_type)->target_type ();
    value *val = std::get<0> (m_storage)->evaluate (expect_type, exp, noside);
    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".

-- 
You are receiving this mail because:
You are on the CC list for the bug.