[Bug c++/15559] New: Method call and calling convention

[Bug c++/15559] New: Method call and calling convention

[kifathegreat at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15559

            Bug ID: 15559
           Summary: Method call and calling convention
           Product: gdb
           Version: 7.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: kifathegreat at gmail dot com

Hello!
I have faced a problem using GDB(7.5, 7.6) with GCC 4.8.0 x86 on Ubuntu 12.04
and Windows XP. Here is the issue description.

GDB has commands to call function from the program being debugged.
They are print and call. But unfortunately the mentioned above commands work
incorrectly for class methods with __thiscall calling convention. Windows x86
targets are using the __thiscall calling convention for C++ class-member
functions by default from GCC 4.7.
Judging by command return values GDB does not set object address (this
pointer) to ECX registry before method call. So these commands trigger for some
object only if last executed line of the program being debugged contains method
call for the same object. In this case ECX registry will contain necessary
address (this pointer). For methods with __cdecl calling convention print
(call) works perfectly.

Thanks,
Kifa

C++ program Test:

01:#include <iostream>
02:class Test
03:{
04:    public:
05:        Test(int value) : _value(value) {}
06:        int value() const __attribute__((thiscall)) { return _value; }
07:    private:
08:        int _value;
09:};
10:int main()
11:{
12:    Test test1(123);
13:    Test test2(456);
14:    int value1 = test1.value();
15:    int value2 = test2.value();
16:    std::cout << value1 + value2 << std::endl;
17:    return 0;
18:}

GDB session:

GNU gdb (GDB) 7.5.1-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) file Test
Reading symbols from /home/kifa/QtCreator/_Test_gcc4.8/Debug/Test...done.
(gdb) break main
Breakpoint 1 at 0x80487fd: file /home/kifa/QtCreator/Test/main.cpp, line 12.
(gdb) run
Starting program: /home/kifa/QtCreator/_Test_gcc4.8/Debug/Test
Breakpoint 1, main () at /home/kifa/QtCreator/Test/main.cpp:12
12     Test test1(123);
(gdb) next
13     Test test2(456);
(gdb) print test1.value()
$1 = -11264
(gdb) next
14     int value1 = test1.value();
(gdb) print test1.value()
$2 = -11264
(gdb) next
15     int value2 = test2.value();
(gdb) print test1.value()
$3 = 123
(gdb) next
16     std::cout << value1 + value2 << std::endl;
(gdb) print test1.value()
$4 = 456
(gdb) next
579
17     return 0;
(gdb) print test1.value()
$5 = 0
(gdb) continue
Continuing.
[Inferior 1 (process 4180) exited normally]
(gdb)

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

asmwarrior <asmwarrior at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asmwarrior at gmail dot com

--- Comment #1 from asmwarrior <asmwarrior at gmail dot com> ---
It is very simple to reproduce this bug:
Test code: (build under GCC 4.7.x or GCC 4.8.x)

#include <string>
#include <vector>

int fff()
{
    return 3;
}

int main()
{
    std::vector<std::string> v;
    v.push_back("a");
    v.push_back("b");
    std::string abc = v[0];
    abc.c_str();
    abc.size();
    int i = v.size();
    i++;
    i = fff();

    return 0;
}


When debugging, you set a bp in the last line:
p v.size() will have such report:

GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(std::vector<std::string, std::allocator<std::string> >::size() const) will be
abandoned.
Program received signal SIGSEGV, Segmentation fault.

p fff() works OK.

This is because std::string::size() is a __thiscall call, but fff() is a
__cdecl calling convention.

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #2 from asmwarrior <asmwarrior at gmail dot com> ---
There is a related discussion about calling stdcall style function under
inferior call, see: https://sourceware.org/ml/gdb/2012-10/msg00061.html, though
stdcall and __thiscall are different.

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #3 from asmwarrior <asmwarrior at gmail dot com> ---
>From what Jon Y said [1]:

QUOTE START:

The previous call convention is __cdecl[1], arguments pushed to stack
right to left, caller unwinds the stack. This convention is used by
Linux SysV ABI and normal C code on Linux and Windows. __thiscall[2] is
a C++ variant of __stdcall[3] where stack is unwound by callee, however
the "this" C++ context is put on the ECX register rather than as a
normal first call argument.

GCC unfortunately does not mangle __cdecl vs __thiscall call convention
into the object symbol tables, this meant you can still link your old
code, but it would fall apart during runtime.

QUOTE END

My question is: how can GDB distinguish between normal functions and class
member functions? Is it possible to distinguish them from debug symbol tables?


[1] http://sourceforge.net/mailarchive/message.php?msg_id=30019808

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #4 from asmwarrior <asmwarrior at gmail dot com> ---
Corinna Vinschen - [RFC] Supporting alternative ABIs -
https://sourceware.org/ml/gdb/2003-08/msg00252.html, by reading this
discussion, I see that some arch already has two calling conversion support.

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #5 from asmwarrior <asmwarrior at gmail dot com> ---
I see that in the file: gdb\sh-tdep.c, the user can specify the calling
convention from the command line, see the source:
-------------------------------------------
void
_initialize_sh_tdep (void)
{
  gdbarch_register (bfd_arch_sh, sh_gdbarch_init, NULL);

  add_prefix_cmd ("sh", no_class, set_sh_command, "SH specific commands.",
                  &setshcmdlist, "set sh ", 0, &setlist);
  add_prefix_cmd ("sh", no_class, show_sh_command, "SH specific commands.",
                  &showshcmdlist, "show sh ", 0, &showlist);

  add_setshow_enum_cmd ("calling-convention", class_vars, sh_cc_enum,
            &sh_active_calling_convention,
            _("Set calling convention used when calling target "
              "functions from GDB."),
            _("Show calling convention used when calling target "
              "functions from GDB."),
            _("gcc       - Use GCC calling convention (default).\n"
              "renesas   - Enforce Renesas calling convention."),
            NULL, NULL,
            &setshcmdlist, &showshcmdlist);
}
-------------------------------------------
The variable sh_active_calling_convention is 0 (default) for sh_cc_gcc calling
convention, and 1 for sh_cc_renesas, there is a function: 

static int
sh_is_renesas_calling_convention (struct type *func_type)

to determine the function calling convention by some checks:
TYPE_CALLING_CONVENTION (func_type) == DW_CC_GNU_renesas_sh....

Finally, the different calling conversion will change the behavior of
sh_push_dummy_call_*, which is the way GDB make a dummy call.

Under MinGW GCC(maybe not limit in Windows system), it looks like the debug
information is not enough. E.g. the sample code build from MinGW GCC 4.6.x or
4.8.1
-------------------------------------------
int f_c_call(int a)
{
    return a;
}

int __attribute__((thiscall)) f_this_call (int b)
{
    return b;
}
class Test
{
    public:
        Test(int value) : _value(value) {}
        int m_f_this_call() const __attribute__((thiscall)) { return _value; }
        int m_f_c_call() const __attribute__((cdecl)) { return _value; }
    private:
        int _value;
};
int main()
{
    Test test1(123);
    Test test2(456);
    int value1 = test1.m_f_c_call();
    int value2 = test2.m_f_this_call();

    value1 = f_c_call(1);
    value2 = f_this_call(2);

    int value3 = value1+value2;
    return 0;
}
-------------------------------------------
Run this inferior under GDB, then type:
maintenance print type f_this_call

result:
type node 0x1b37c58
name '<NULL>' (0x0)
tagname '<NULL>' (0x0)
code 0x7 (TYPE_CODE_FUNC)
length 1
objfile 0x1b29990
target_type 0x1b333c8
  type node 0x1b333c8
  name 'int' (0x1b34b35)
  tagname '<NULL>' (0x0)
  code 0x8 (TYPE_CODE_INT)
  length 4
  objfile 0x1b29990
  target_type 0x0
  pointer_type 0x0
  reference_type 0x0
  type_chain 0x1b333c8
  instance_flags 0x0
  flags
  nfields 0 0x0
  vptr_basetype 0x0
  vptr_fieldno -1
pointer_type 0x0
reference_type 0x0
type_chain 0x1b37c58
instance_flags 0x0
flags TYPE_FLAG_PROTOTYPED
nfields 1 0x1b37cb0
  [0] bitpos 0 bitsize 0 type 0x1b333c8 name '<NULL>' (0x0)
    type node 0x1b333c8
    name 'int' (0x1b34b35)
    tagname '<NULL>' (0x0)
    code 0x8 (TYPE_CODE_INT)
    length 4
    objfile 0x1b29990
    target_type 0x0
    pointer_type 0x0
    reference_type 0x0
    type_chain 0x1b333c8
    instance_flags 0x0
    flags
    nfields 0 0x0
    vptr_basetype 0x0
    vptr_fieldno -1
vptr_basetype 0x0
vptr_fieldno -1
calling_convention 1

Type maintenance print type f_c_call, maintenance print type f_c_call,
maintenance print type Test::m_f_c_call, maintenance print type
Test::m_f_this_call, all gives the same result of "calling_convention 1".

So, I think a work around is do the same thing like in "sh-tdep.c", that is: we
see the inferior is build from GCC 4.7 or later, we need to check the
calling_convention by some code snippet like:

TYPE_CODE (func_type) == TYPE_CODE_FUNC and this is a member function

then we should modify the i386_push_dummy_call like function in i386-tdep.c,
oh, do we need a i386-windows-tdeps.c? I see there are files named
amd64-windows-tdeps.c, i386-cygwin-tdeps.c, but I don't see
i386-windows-tdeps.c, the reason may be that i386-tdep.c is a good place to put
the change?

I'm sorry I can't go further to implement this, but I hope some guys can help
to improve this, thanks.

Yuanhui Zhang

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #6 from asmwarrior <asmwarrior at gmail dot com> ---
OK, the tiny patch can fix this issue, note this is only for GCC under Windows,
the GCC version should be 4.7.x or later, comments are welcome.

See below:

 gdb/i386-tdep.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index b159b49..db160ba 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -2408,6 +2408,20 @@ i386_push_dummy_call (struct gdbarch *gdbarch, struct
value *function,
   int i;
   int write_pass;
   int args_space = 0;
+  struct type *func_type = value_type (function);
+  int i386_windows_thiscall = 0;
+
+  if (func_type)
+    {
+      if( (TYPE_CODE (func_type) == TYPE_CODE_METHOD) && (nargs > 0))
+        {
+         /* a.f(5,6);
+            args[0] = this pointer;
+            args[1] = 5;
+            args[2] = 6; */
+         i386_windows_thiscall = 1;
+        }
+    }

   /* Determine the total space required for arguments and struct
      return address in a first pass (allowing for 16-byte-aligned
@@ -2430,7 +2444,7 @@ i386_push_dummy_call (struct gdbarch *gdbarch, struct
value *function,
         args_space += 4;
     }

-      for (i = 0; i < nargs; i++)
+      for (i = i386_windows_thiscall; i < nargs; i++)
     {
       int len = TYPE_LENGTH (value_enclosing_type (args[i]));

@@ -2482,6 +2496,12 @@ i386_push_dummy_call (struct gdbarch *gdbarch, struct
value *function,
   /* ...and fake a frame pointer.  */
   regcache_cooked_write (regcache, I386_EBP_REGNUM, buf);

+  if (i386_windows_thiscall)
+    {
+      /* args[0] refer to the last argument which is the this pointer */
+      regcache_cooked_write (regcache, I386_ECX_REGNUM,
value_contents_all(args[0]));
+    }
+
   /* MarkK wrote: This "+ 8" is all over the place:
      (i386_frame_this_id, i386_sigtramp_frame_this_id,
      i386_dummy_id).  It's there, since all frame unwinders for

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

[Bug c++/15559] Method call and calling convention

[xunxun1982 at gmail dot com]

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

xunxun <xunxun1982 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xunxun1982 at gmail dot com

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #7 from asmwarrior <asmwarrior at gmail dot com> ---
Created attachment 7225
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7225&action=edit
handling thiscall calling convention for Windows GCC 7.4.0+ on x86

Use thiscall calling convention for x86 mingw gcc 4.7.0 and above in C++ class
method, borrow some code from sh-tdep.c to handling function typedef and
pointers for thiscall calling convention, also there is a hack (global
variable) to tell i386_push_dummy_call() function that whether it is a static
member function call, it is better to pass this variable in function arguments,
but this will make a lot of other changes.

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #8 from asmwarrior <asmwarrior at gmail dot com> ---
Created attachment 7227
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7227&action=edit
generate correct calling convention according to GCC version detection

This is the improved version of the previous patch v2, in this version, the gcc
version is detected so that correctly calling convention can be generated. The
bad thing is that I still use global variables to translate information, I need
to find a better and clean way.

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

[Bug c++/15559] Method call and calling convention

[i.nixman at gmail dot com]

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

niXman <i.nixman at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i.nixman at gmail dot com

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

[Bug c++/15559] Method call and calling convention

[i.nixman at autistici dot org]

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

--- Comment #9 from niXman <i.nixman at autistici dot org> ---
This patches will be acepted in GDB?

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #10 from asmwarrior <asmwarrior at gmail dot com> ---
Hi, nixman, I think it won't, if you look at my patch, I use some global
variables to translate the information from one module to another module.

Currently, both the Linux and Windows 32 bit i386 inferior call code was in a
uniformed method (all in i386-tdep.c). 

If we need to distinguish them, we may need to create some new file like:
i386-windows-tdeps.c, which handle the special Windows 32 bit inferior calls. 
(This is something similar to what amd64-windows-tdeps.c does)

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

[Bug c++/15559] Method call and calling convention

[ssbssa at yahoo dot de]

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

Domani Hannes <ssbssa at yahoo dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at yahoo dot de

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

[Bug c++/15559] Method call and calling convention

[ssbssa at yahoo dot de]

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

--- Comment #11 from Domani Hannes <ssbssa at yahoo dot de> ---
Created attachment 7438
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7438&action=edit
use thiscall calling convention for class members

This uses the debug information to detect if thiscall calling convention should
be used.

It's kinda ugly since I used the DWARF codes directly.

And I couldn't figure out if there is a way to get the first function-argument
(instead of the 'this' symbol), since it's possible to use thiscall for
non-member functions as well.

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #12 from asmwarrior <asmwarrior at gmail dot com> ---
Hi, Domani Hannes, thanks for the patch. I just tested it, but it failed on
testing the sample code in comment 1 when I type "p v.size()".

The BT is below:
[debug]> bt 30
[debug]#0  0x005a0ed9 in dwarf2_per_cu_objfile (per_cu=0xbaadf00d) at
f:\build_gdb\binutils-gdb\gdb\dwarf2read.c:20999
[debug]#1  0x005b21a0 in dwarf2_find_location_expression (baton=0x302e7e8,
locexpr_length=0x2a4f234, pc=0) at
f:\build_gdb\binutils-gdb\gdb\dwarf2loc.c:214
[debug]#2  0x005b25b8 in loclist_find_frame_base_location (framefunc=0x302e7b8,
pc=0, start=0x2a4f238, length=0x2a4f234) at
f:\build_gdb\binutils-gdb\gdb\dwarf2loc.c:410
[debug]#3  0x00408d0f in i386_push_dummy_call (gdbarch=0x2f76480,
function=0x4daf590, regcache=0x4df70c0, bp_addr=2293391, nargs=1,
args=0x2a4f464, sp=2293376, struct_return=0, struct_addr=0) at
f:\build_gdb\binutils-gdb\gdb\i386-tdep.c:2561
[debug]#4  0x0053cdc6 in gdbarch_push_dummy_call (gdbarch=0x2f76480,
function=0x4daf590, regcache=0x4df70c0, bp_addr=2293391, nargs=1,
args=0x2a4f464, sp=2293376, struct_return=0, struct_addr=0) at
f:\build_gdb\binutils-gdb\gdb\gdbarch.c:2117
[debug]#5  0x00510299 in call_function_by_hand (function=0x4daf590, nargs=1,
args=0x2a4f464) at f:\build_gdb\binutils-gdb\gdb\infcall.c:752
[debug]#6  0x004d9658 in evaluate_subexp_standard (expect_type=0x0,
exp=0x4debb20, pos=0x2a4f84c, noside=EVAL_NORMAL) at
f:\build_gdb\binutils-gdb\gdb\eval.c:1764
[debug]#7  0x005d7040 in evaluate_subexp_c (expect_type=0x0, exp=0x4debb20,
pos=0x2a4f84c, noside=EVAL_NORMAL) at
f:\build_gdb\binutils-gdb\gdb\c-lang.c:720
[debug]#8  0x004d5a36 in evaluate_subexp (expect_type=0x0, exp=0x4debb20,
pos=0x2a4f84c, noside=EVAL_NORMAL) at f:\build_gdb\binutils-gdb\gdb\eval.c:70
[debug]#9  0x004d5bb5 in evaluate_expression (exp=0x4debb20) at
f:\build_gdb\binutils-gdb\gdb\eval.c:145
[debug]#10 0x004eec79 in print_command_1 (exp=0x2a4f9f2 "v.size()",
voidprint=1) at f:\build_gdb\binutils-gdb\gdb\printcmd.c:977
[debug]#11 0x004eed84 in print_command (exp=0x2a4f9f2 "v.size()", from_tty=1)
at f:\build_gdb\binutils-gdb\gdb\printcmd.c:1009
[debug]#12 0x0044d264 in do_cfunc (c=0x2f4f850, args=0x2a4f9f2 "v.size()",
from_tty=1) at f:\build_gdb\binutils-gdb\gdb\cli\cli-decode.c:107
[debug]#13 0x0044fb54 in cmd_func (cmd=0x2f4f850, args=0x2a4f9f2 "v.size()",
from_tty=1) at f:\build_gdb\binutils-gdb\gdb\cli\cli-decode.c:1886
[debug]#14 0x00611954 in execute_command (p=0x2a4f9f9 ")", from_tty=1) at
f:\build_gdb\binutils-gdb\gdb\top.c:458
[debug]#15 0x00457658 in safe_execute_command (command_uiout=0x2f72b08,
command=0x2a4f9f0 "p v.size()", from_tty=1) at
f:\build_gdb\binutils-gdb\gdb\cli\cli-interp.c:124
[debug]#16 0x004575d3 in cli_interpreter_exec (data=0x0, command_str=0x4c40758
"p v.size()") at f:\build_gdb\binutils-gdb\gdb\cli\cli-interp.c:107
[debug]#17 0x0052e452 in interp_exec (interp=0x2f72ba8, command_str=0x4c40758
"p v.size()") at f:\build_gdb\binutils-gdb\gdb\interps.c:356
[debug]#18 0x0045d878 in mi_cmd_interpreter_exec (command=0x78663d <procs+2845>
"-interpreter-exec", argv=0x2a4fad4, argc=2) at
f:\build_gdb\binutils-gdb\gdb\mi\mi-interp.c:246
[debug]#19 0x004623c3 in captured_mi_execute_command (uiout=0x2f79a38,
context=0x3014fa0) at f:\build_gdb\binutils-gdb\gdb\mi\mi-main.c:1985
[debug]#20 0x00462698 in mi_execute_command (cmd=0x4c40810 "p v.size()",
from_tty=1) at f:\build_gdb\binutils-gdb\gdb\mi\mi-main.c:2074
[debug]#21 0x0045d92a in mi_execute_command_wrapper (cmd=0x4c40810 "p
v.size()") at f:\build_gdb\binutils-gdb\gdb\mi\mi-interp.c:291
[debug]#22 0x0045d93d in mi_execute_command_input_handler (cmd=0x4c40810 "p
v.size()") at f:\build_gdb\binutils-gdb\gdb\mi\mi-interp.c:299
[debug]#23 0x00536bcd in gdb_readline2 (client_data=0x0) at
f:\build_gdb\binutils-gdb\gdb\event-top.c:713
[debug]#24 0x005364ad in stdin_event_handler (error=0, client_data=0x0) at
f:\build_gdb\binutils-gdb\gdb\event-top.c:375
[debug]#25 0x005356fa in handle_file_event (data=...) at
f:\build_gdb\binutils-gdb\gdb\event-loop.c:768
[debug]#26 0x00534e48 in process_event () at
f:\build_gdb\binutils-gdb\gdb\event-loop.c:342
[debug]#27 0x00534f0d in gdb_do_one_event () at
f:\build_gdb\binutils-gdb\gdb\event-loop.c:406
[debug]#28 0x00534f5e in start_event_loop () at
f:\build_gdb\binutils-gdb\gdb\event-loop.c:431
[debug]#29 0x0045d998 in mi_command_loop (data=0x2f79578) at
f:\build_gdb\binutils-gdb\gdb\mi\mi-interp.c:316
[debug](More stack frames follow...)

In the code:
struct objfile *objfile = per_cu->objfile;
I see that per_cu can't be accessed, see the log:
[debug]> whatis per_cu
[debug]type = struct dwarf2_per_cu_data *
[debug]>>>>>>cb_gdb:
[debug]> output per_cu
[debug](struct dwarf2_per_cu_data *) 0xbaadf00d>>>>>>cb_gdb:
[debug]> output *per_cu
[debug]Cannot access memory at address 0xbaadf00d
[debug]>>>>>>cb_gdb:

Yuanhui Zhang

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

[Bug c++/15559] Method call and calling convention

[ssbssa at yahoo dot de]

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

Domani Hannes <ssbssa at yahoo dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #7438|0                           |1
        is obsolete|                            |

--- Comment #13 from Domani Hannes <ssbssa at yahoo dot de> ---
Created attachment 7443
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7443&action=edit
use thiscall calling convention for class members (try 2)

This is a (mostly) similar approach, but now I use tracepoint_var_ref(), which
translates the debug information into an agent expression.

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #14 from asmwarrior <asmwarrior at gmail dot com> ---
Hi, Domani Hannes, thank you for the hard work, with your version 2 patch, now
"p v.size()" works OK in comment 1, but "p abc.c_str()" still let GDB crash. 

I don't understand much about your patch, my knowledge on GDB is much less than
yours.

PS: my patch attachment 7227 works OK on those tests in comment 1.

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

[Bug c++/15559] Method call and calling convention

[ssbssa at yahoo dot de]

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

--- Comment #15 from Domani Hannes <ssbssa at yahoo dot de> ---
Hello asmwarrior

Yes, looks like my strategy doesn't work in every situation.
find_pc_function() can fail (maybe because of some missing debug information?),
then it just stops looking.
A minimal_symbol would still be available, but it's not really useful for this
situation.

I looked at your code again as well.
find_pc_symtab(find_function_addr(function,NULL)) would work as well, so we
don't need that global i386_windows_build_gt_gcc46.

But I found no way to locally find out if it's a static function.
There is function->type->main_type->flag_static, but it's always 0 (and as far
as I can tell not used).

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #16 from asmwarrior <asmwarrior at gmail dot com> ---
(In reply to Domani Hannes from comment #15)
> Hello asmwarrior
> 
> Yes, looks like my strategy doesn't work in every situation.
> find_pc_function() can fail (maybe because of some missing debug
> information?), then it just stops looking.
> A minimal_symbol would still be available, but it's not really useful for
> this situation.
> 
> I looked at your code again as well.
> find_pc_symtab(find_function_addr(function,NULL)) would work as well, so we
> don't need that global i386_windows_build_gt_gcc46.

Hi, Domani Hannes, thanks, this can simplify my original patch, so I don't need
to touch the infcall.c now, I have tested the new way you suggested, and it
works fine. I will upload the new patch (version 3) of my patch soon.

> 
> But I found no way to locally find out if it's a static function.
> There is function->type->main_type->flag_static, but it's always 0 (and as
> far as I can tell not used).
So, we can't use this flag. Currently, in my patch, whether a function is a
static member function is retrieved from gdb/eval.c, but I don't see it use the
function->type->main_type->flag_static either.

In infcall.c, it use a function to get whether a function is static:

          (void) find_overload_match (&argvec[1], nargs, tstr,
                                      METHOD, /* method */
                      &arg2,  /* the object */
                      NULL, &valp, NULL,
                      &static_memfuncp, 0);

But the function find_overload_match is quite complex, I don't dig enough to
its body, it looks like in

int
find_overload_match (struct value **args, int nargs,
             const char *name, enum oload_search_type method,
             struct value **objp, struct symbol *fsym,
             struct value **valp, struct symbol **symp, 
             int *staticp, const int no_adl)
{
There are two places to update the *staticp.


Yuanhui Zhang (asmwarrior)

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

asmwarrior <asmwarrior at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #7225|0                           |1
        is obsolete|                            |
   Attachment #7227|0                           |1
        is obsolete|                            |

--- Comment #17 from asmwarrior <asmwarrior at gmail dot com> ---
Created attachment 7448
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7448&action=edit
handling thiscall calling convention for Windows(V3)

This new patch(v3) was suggested by Hannes Domani in comment 15.

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

[Bug c++/15559] Method call and calling convention

[julian at codesourcery dot com]

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

julian at codesourcery dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julian at codesourcery dot com

--- Comment #18 from julian at codesourcery dot com ---
I posted a patch here:

https://sourceware.org/ml/gdb-patches/2014-03/msg00610.html

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

[Bug c++/15559] Method call and calling convention

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hannes Domani <ssbssa@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=627c7fb8ea16388f349b6b26e20bf017d71e51fe

commit 627c7fb8ea16388f349b6b26e20bf017d71e51fe
Author: Hannes Domani <ssbssa@yahoo.de>
Date:   Mon Apr 27 15:58:09 2020 +0200

    Use thiscall calling convention for class members

    Non-static member functions for Windows 32bit programs need the thiscall
    calling convention, so the 'this' pointer needs to be passed in ECX.

    gdb/ChangeLog:

    2020-04-30  Hannes Domani  <ssbssa@yahoo.de>

            PR gdb/15559
            * i386-tdep.c (i386_push_dummy_call): Call
            i386_thiscall_push_dummy_call.
            (i386_thiscall_push_dummy_call): New function.
            * i386-tdep.h (i386_thiscall_push_dummy_call): Declare.
            * i386-windows-tdep.c (i386_windows_push_dummy_call): New function.
            (i386_windows_init_abi): Call set_gdbarch_push_dummy_call.

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

[Bug c++/15559] Method call and calling convention

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |ssbssa at sourceware dot org

--- Comment #24 from Hannes Domani <ssbssa at sourceware dot org> ---
Fixed.

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

[Bug c++/15559] Method call and calling convention

[asmwarrior at gmail dot com]

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

--- Comment #25 from asmwarrior <asmwarrior at gmail dot com> ---
Hi, Hannes Domani, thanks for the commit! Great work!

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