Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDB 7.10 from NDK r11b returns inconsistent MI result record for -exec-step command #60

Closed
dosvidos opened this issue Mar 31, 2016 · 4 comments
Assignees
Labels

Comments

@dosvidos
Copy link

I'm debugging UE4 demo with GDB 7.10 from NDK R11B for Windows 64-bit connected to AARCH64 API23 target.
Sometimes, GDB responds with seemingly incorrect async MI result record after the target's execution is resumed by -exec-step command.
According to GDB MI documentation and GDB test suite I expect that in this case the MI result record should always contain a reason field: *stopped,reason="end-stepping-range"
This is also baked by changelog note
2009-02-14 Vladimir Prus [email protected]
* lib/mi-support.exp (mi_expect_stop): Adjust the order of fields.
(mi_expect_interrupt): Likewise.
* gdb.mi/mi-cli.exp: Check that "step" results in proper *stopped
response.
and test cases defined in
binutils-gdb/gdb/testsuite/gdb.mi/mi-cli.exp
This stop without a reason behavior is irritating, because it doesn't fit into expected response pattern. Should the front-end treat a step request as successfully completed after receiving this notification record? This inconsistency requires additional and unnecessary decision-making logic on the front-end.

2016-03-31 17:45:27.7085[GDB] cmd: "46-exec-step --thread 10"
2016-03-31 17:45:27.7390[GDB] stdout: 46^running
2016-03-31 17:45:27.7390[GDB] stdout: *running,thread-id="all"
2016-03-31 17:45:27.9372[GDB] stdout: *stopped,reason="end-stepping-range",frame={addr="0x5247895c",func="FString::FString",args=[{name="this",value="0x597ed088"},{name="Src",value="0x592cc53d "/UE4Game/""},{name="Dummy",value="0x0"}],file="Runtime/Core/Public\Containers/UnrealString.h",fullname="C:\UnrealEngine-4.10\Engine\Source\Runtime\Core\Public\Containers\UnrealString.h",line="124"},thread-id="10",stopped-threads="all",core="1"

2016-03-31 17:45:34.8915[GDB] cmd: "67-exec-finish --thread 10 --frame 0"
2016-03-31 17:45:34.9205[GDB] stdout: 67^running
2016-03-31 17:45:34.9205[GDB] stdout: *running,thread-id="all"
2016-03-31 17:45:36.5448[GDB] stdout: *stopped,reason="end-stepping-range",frame={addr="0x52478a40",func="InitCommandLine",args=[],file="C:\UnrealEngine-4.10\Engine\Source\Runtime\Launch\Private\Android/LaunchAndroid.cpp",fullname="C:\UnrealEngine-4.10\Engine\Source\Runtime\Launch\Private\Android\LaunchAndroid.cpp",line="168"},thread-id="10",stopped-threads="all",core="1"

2016-03-31 17:45:38.9636[GDB] cmd: "89-exec-step --thread 10"
2016-03-31 17:45:38.9936[GDB] stdout: *running,thread-id="all"
2016-03-31 17:45:38.9936[GDB] stdout: 89^running
2016-03-31 17:45:39.1102[GDB] stdout: *stopped,reason="end-stepping-range",frame={addr="0x52478a4c",func="operator+(FString const&, FString&&)",args=[{name="Lhs",value="..."},{name="Rhs",value="<unknown type in C:\UnrealEngine-4.10\NVIDIA_Android_Lab_GDC2016\Binaries\Android\libUE4.so, CU 0x0, DIE 0x2155ba>"}],file="Runtime/Core/Public\Containers/UnrealString.h",fullname="C:\UnrealEngine-4.10\Engine\Source\Runtime\Core\Public\Containers\UnrealString.h",line="679"},thread-id="10",stopped-threads="all",core="1"

2016-03-31 17:45:41.0039[GDB] cmd: "106-exec-finish --thread 10 --frame 0"
2016-03-31 17:45:41.0322[GDB] stdout: 106^running
2016-03-31 17:45:41.0322[GDB] stdout: *running,thread-id="all"
2016-03-31 17:45:47.2672[GDB] stdout: *stopped,reason="end-stepping-range",frame={addr="0x524791f4",func="InitCommandLine",args=[],file="C:\UnrealEngine-4.10\Engine\Source\Runtime\Launch\Private\Android/LaunchAndroid.cpp",fullname="C:\UnrealEngine-4.10\Engine\Source\Runtime\Launch\Private\Android\LaunchAndroid.cpp",line="168"},thread-id="10",stopped-threads="all",core="1"

2016-03-31 17:45:56.8990[GDB] cmd: "128-exec-step --thread 10"
2016-03-31 17:45:56.9080[GDB] stdout: *running,thread-id="all"
2016-03-31 17:45:56.9080[GDB] stdout: 128^running
2016-03-31 17:45:56.9080[GDB TargetState] targetIsRunning is changed from False to True
2016-03-31 17:45:56.9300[GDB] stdout: ~"FApp::IsGameNameEmpty () at Runtime/Core/Public/Misc/App.h:180\n"
2016-03-31 17:45:56.9300[GDB] stdout: ~"180\t\t\treturn (GInternalGameName[0] == 0);\n"
2016-03-31 17:45:56.9300[GDB] stdout: *stopped,frame={addr="0x524791f4",func="FApp::IsGameNameEmpty",args=[],file="Runtime/Core/Public/Misc/App.h",fullname="C:\UnrealEngine-4.10\Engine\Source\Runtime\Core\Public\Misc\App.h",line="180"},thread-id="10",stopped-threads="all",core="1"

@dosvidos
Copy link
Author

The func="FApp::IsGameNameEmpty" is defined in a header file and decorated with
#define FORCEINLINE inline __attribute__ ((always_inline)) /* Force code to be inline */ FORCEINLINE static bool IsGameNameEmpty() { return (GInternalGameName[0] == 0); }
But the same attribute is applied to func="FString::FString" and func="operator+(FString const&, FString&&)" and yet for both of them GDB outputs the expected response *stopped,reason="end-stepping-range"

@jmgao
Copy link
Contributor

jmgao commented Apr 26, 2016

Try gdb 7.11 from the r12 beta, we've had internal reports of single stepping being broken with 7.10 that were resolved with 7.11.

@DanAlbert DanAlbert added the gdb label Aug 9, 2016
@DanAlbert
Copy link
Member

Is this fixed?

@DanAlbert
Copy link
Member

Re-open if this is still present in r12.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants