Frame issue with the debugger plugin

[Jenna]

It seems that commit 10539 together with 10540 break 32-bit build on linux.
See this error log-snippet:

Code Select Expand

debuggermanager.cpp: In function 'uint64_t cbDebuggerStringToAddress(const wxString&)':
debuggermanager.cpp:488:36: error: no matching function for call to 'wxString::ToULong(uint64_t*, int) const'
     if (address.ToULong(&result, 16))
                                    ^
In file included from /usr/include/wx-2.8/wx/artprov.h:15:0,
                 from debuggermanager.cpp:12:
/usr/include/wx-2.8/wx/string.h:1188:10: note: candidate: bool wxString::ToULong(long unsigned int*, int) const
     bool ToULong(unsigned long *val, int base = 10) const;
          ^
/usr/include/wx-2.8/wx/string.h:1188:10: note:   no known conversion for argument 1 from 'uint64_t* {aka long long unsigned int*}' to 'long unsigned int*'

The cause is the use of this newly added function:

Code (diff) Select Expand

@@ -459,6 +472,30 @@ wxString cbDetectDebuggerExecutable(const wxString &exeName)
     return exePath + wxFileName::GetPathSeparator() + exeName + exeExt;
}

+uint64_t cbDebuggerStringToAddress(const wxString &address)
+{
+    if (address.empty())
+        return 0;
+#if defined(__WXMSW__)
+    // Workaround for the 'ToULongLong' bug in wxWidgets 2.8.12
+#if wxCHECK_VERSION(2, 8, 12)
+    return strtoull(address.mb_str(), nullptr, 16);
+#else
+    uint64_t result;
+    if (address.ToULongLong(&result))
+        return result;
+    else
+        return 0;
+#endif // wxCHECK_VERSION
+#else
+    uint64_t result;
+    if (address.ToULong(&result, 16))
+        return result;
+    else
+        return 0;
+#endif
+}
+

class DebugTextCtrlLogger : public TextCtrlLogger
{


(1) Is there any reason for the #if defined(__WXMSW__) ?
(2) And if yes, shouldn't it be address.ToUlongLong in the else-clause ?

Or in other words, is the ToUlongLong-bug (which ?) a windows-only (2) bug or is it a bug on all systems (1) ?

[oBFusCATed]

(1) Is there any reason for the #if defined(__WXMSW__) ?
(2) And if yes, shouldn't it be address.ToUlongLong in the else-clause ?

Or in other words, is the ToUlongLong-bug (which ?) a windows-only (2) bug or is it a bug on all systems (1) ?

This is the original topic http://forums.next.codeblocks.org/index.php/topic,20155.0.html
I think you can find the bug report about toulonglong there.
Probably I've messed it a bit here.
We should always use ToULongLong on windows, because sizeof(long)==4 there.
See this table https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

Probably we should use ToULongLong on 32bit linux/osx. Can you detect this case?

Also can you move these two posts in the original topic?

[Jenna]

Also can you move these two posts in the original topic?

Done.

Probably we should use ToULongLong on 32bit linux/osx. Can you detect this case?

I think this should work.
I can test the build on my copr-site, but not whether it works or not (at the moment).
I'm not at home until sunday, so I can not set up a 32bit test-machine (too slow internet) and I will only be at home for some hours sunday evening.

[Jenna]

Another thing I just stumbled about:
all calls of string2ulong[long] in the cbDebuggerStringToAddress-function have a base of 16, except the ToULongLong-call for wx > 2.8.12 on windows.

[oBFusCATed]

This last thing is a bug, if you're committing please fix it.

[Jenna]

In trunk.
I need to distinguish between 64bit and 32bit, because of the different size of long/long long.
It builds now, but is not tested on 32bit linux and not tested at all on Mac.