[aqualung99]

It’s not really inconvenient. It’s more a matter that the default behavior is “wrong” — i.e. launching my program with the debugger is not (necessarily) going to do the same thing as launching my program directly (because the same activity may not get launched.)
So, I’m inclined to say, the default behavior should be changed such that instead of launching the first activity found in the list, the front end should determine which activity to launch by examining the AndroidManifest.xml file.
However, that said, I can perhaps see some benefit in being able to direct the debugger to launch a specific activity, rather than the default startup one. In that case, being able to direct the debugger (in any way — UI, editing a file, whatever) is desirable.
You guys have a quality product, I’ll leave it to you what you think you should do. But I do think the current behavior needs at least a warning or something if the debugger decides to launch a different activity than the one bound to the LAUNCHER and MAIN commands. I don’t think the average user will expect that behavior.

[aqualung99]

And thank you for the help! I’ve tested and confirmed your hypothesis, ARM toolchain seems to work fine. 🙂
Of course I’ve already gotten spoiled by HAXM…I supposed I’ll have to work with my real device now… 😉

[aqualung99]

No problem. It’s too big to include here (by almost double) so I’ve attached it as a separate file.

[attachment=1:187uuw55]VisualGDB info.zip[/attachment:187uuw55]

Hope it’s helpful! 🙂

Edit: Hmm, could it be the lower-case ‘r’ drive letter vs. the upper-case ‘R’ drive letter?? Where did that lower-case one come from? 🙂

Edit 2: Here’s Visual GDB’s startup output in case it’s helpful: [attachment=0:187uuw55]VisualGDB startup.zip[/attachment:187uuw55]

[aqualung99]

Thank you for your reply. That page was helpful for me understanding what was going on, at least partially. I had paths of the form:

r:/Projects/VA128//jni/arch_android.cpp

in my “info sources” but paths of the form

r:ProjectsVA128/jni/arch_android.cpp

were expected by my .so file. From the helpful page you sent me:

Note that GDB requires the file path to be EXACTLY the same as reported by “info sources”, including double slash before “jni”.

A clean build using VisualGDB’s built-in make commands resolved that problem. Nice!
Unfortunately, it’s still not working. But now, I get this:

^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="",pending="r:/Projects/VA128//jni/arch_android.cpp:118",times="0",original-location="r:/Projects/VA128//jni/arch_android.cpp:118"}

-var-create --frame 0 --thread 1 - * "pGL"

-var-create: unable to create variable object

Not quite sure what to do next 🙂

[Author]

Posts