Home » Language IDEs » C / C++ IDE (CDT) » Crosscompiled debuging [SOLVED](Issue getting it working on Eclipse 4.4 / 4.7 and gdb 7.12 )
| Crosscompiled debuging [SOLVED] [message #1770451] |
Fri, 11 August 2017 15:45  |
 Anton Krug
Messages: 9
Registered: August 2017 |
Junior Member |
|
|
Hello Everybody,
This is my first post here so I hope I'm posting it to the right place. I have a riscv system, toolchain is compiled from their repositories (github / riscv - can't post links yet). And I wonder what exactly eclipse does when it tries to start debugging.
I tried first the same process on Eclipse 3.6 and with enabled gdb traces I see the eclipse is entering the directory straight away, doesn't even care about the gdb version (I replaced the real paths with just placeholders):
681,687 1-environment-cd <MY-WORKSPACE>
681,688 1^done
681,702 (gdb)
681,704 2-file-exec-and-symbols <PATH-TO-ELF>
681,858 3-list-thread-groups
682,120 2^done
682,120 (gdb)
682,120 3^done,groups=[{id="i1",type="process",executable="<PATH-TO-ELF>"}]
682,120 (gdb)
682,122 4-gdb-set auto-solib-add on
682,125 4^done
682,125 (gdb)
This setup works and I can debug without issues. When I try to replicate the same on 4.4 or 4.7 I get problems. It starts with the eclipse not supplying the file even if it's specified in the configuration. Even if I supply the file then I get lot of other issues later on, so even if the file wouldn't deal breaker, I think it's the first sign that something wrong is happening. The session starts with the version being polled and the it behaves a bit differently (same toolchain, equivalent of the same settings, same project etc...):
248,869 2-gdb-version
248,870 ~"GNU gdb (GDB) 7.12.50.20170504-git\n"
248,881 ~"Copyright (C) 2016 Free Software Foundation, Inc.\n"
248,882 ~"License GPLv3+: GNU GPL version 3 or later <CAN POST LINKS WITH NEW FORUM ACCOUNT >\nThis is fre\
e software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitt\
ed by law. Type \"show copying\"\nand \"show warranty\" for details.\n"
248,882 ~"This GDB was configured as \"--host=i686-pc-linux-gnu --target=riscv64-unknown-elf\".\nTyp\
e \"show configuration\" for configuration details."
248,882 ~"\nFor bug reporting instructions, please see:\n"
248,882 ~"< CAN POST LINKS WITH NEW FORUM ACCOUNT />.\n"
248,883 ~"Find the GDB manual and other documentation resources online at:\n<CAN POST LINKS WITH NEW FORUM ACCOUNT />.\n"
248,883 ~"For help, type \"help\".\n"
248,883 ~"Type \"apropos word\" to search for commands related to \"word\".\n"
248,883 2^done
248,884 (gdb)
248,885 3-environment-cd <MY-WORKSPACE>
248,885 3^done
248,885 (gdb)
248,886 4-gdb-set breakpoint pending on
248,886 4^done
248,886 (gdb)
248,887 5maintenance set python print-stack off
248,887 &"maintenance set python print-stack off\n"
248,887 &"Undefined maintenance set command: \"python print-stack off\". Try \"help maintenance set\
\".\n"
248,887 5^error,msg="Undefined maintenance set command: \"python print-stack off\". Try \"help main\
tenance set\"."
248,887 (gdb)
248,888 6-gdb-set print object off
248,888 6^done
248,888 (gdb)
248,889 7-gdb-set print sevenbit-strings on
248,889 7^done
248,889 (gdb)
248,890 8-gdb-set host-charset UTF-8
248,890 8^done
248,890 (gdb)
248,891 9-gdb-set target-charset UTF-8
248,891 9^done
248,891 (gdb)
248,893 10-gdb-set target-wide-charset UTF-32
248,894 10^done
248,896 (gdb)
248,899 11-gdb-set target-async off
248,899 11^done
248,899 (gdb)
248,900 12-gdb-set auto-solib-add on
248,900 12^done
248,900 (gdb)
248,903 13-target-select extended-remote localhost:10000
248,907 =thread-group-started,id="i1",pid="42000"
248,907 &"warning: No executable has been specified and target does not support\ndetermining executa\
ble automatically. Try using the \"file\" command."
248,907 &"\n"
248,907 =thread-created,id="1",group-id="i1"
248,908 =thread-group-exited,id="i1"
248,908 13^error,msg="Truncated register 32 in remote 'g' packet"
248,908 (gdb)
248,911 14-list-thread-groups --available
248,911 14^error,msg="Don't know how to get OS data. Try \"help target\"."
248,911 (gdb)
248,960 15-gdb-exit
248,960 15^exit
Is my gdb returning wrong version syntax, confusing the eclipse to be something else and then making it to make a decision and behave differently then it should?
For example with ARM I see straight away it is not x86 gdb:
"GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.1.20141128-cvs"
while with the riscv it could be confused for a native gdb while clearly it is not?
Part of problem might be that the gdb service on another side might not be the same version supporting same features, so the version can confuse the eclipse using more recent feature then my whole setup can do. Could somebody point me what I could do next?
Or point me to the source code where the eclipse is checking for the version to see if something is badly detected. Sadly I couldn't even find table what version with what eclipses with what features should be compatible.
Thank you very much in advance for any hints or advice.
Best regards,
Anton
[Updated on: Tue, 22 August 2017 15:45] Report message to a moderator |
|
|
| Re: Crosscompiled debuging. [message #1770545 is a reply to message #1770451] |
Mon, 14 August 2017 09:08  |
Jonah Graham
Messages: 416
Registered: June 2014 |
Senior Member |
|
|
I'll try to answer some of your questions about versions, but please come back with follow up questions....
There was a bug that meant that GDB 7.10+ was identified as GDB 7.1. That bug was fixed in late 2015: https://bugs.eclipse.org/bugs/show_bug.cgi?id=476432#c1
The collection of version number in your trace (command 2 in your trace) is purely a debugging feature so that reading traces is easier. That invocation of version info is simply not used by the code. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=455408 and http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/launching/FinalLaunchSequence.java?id=e8bfecea0bd1de460f3e855c210ecc446e8bb7c9#n192 for the code that requests and receives the response. As you can see, it does nothing with the version number.
The version of GDB is used, but a separate invocation of GDB is used to get just the version number. It needs to be a pre-step, because even the launch arguments for GDB within CDT depend on the version of GDB. The version number is obtained from http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/launching/GdbLaunch.java?id=e8bfecea0bd1de460f3e855c210ecc446e8bb7c9#n511
This version number is used to create the correct version of many services. See http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GdbDebugServicesFactory.java?id=e8bfecea0bd1de460f3e855c210ecc446e8bb7c9 for the if statements that depend on the version number.
If you want to see if the version compare is working as expected, debug org.eclipse.cdt.dsf.gdb.launching.LaunchUtils.compareVersions(String, String)
The above is all caveated by one thing, the links I have given are for Local C/C++ Launch, the remote launch may override some of these things. For example, the version comparison bug 476432 did propagate to other code bases and perhaps there are places that haven't been fixed.
HTH
Jonah
|
|
| |
| Re: Crosscompiled debuging. [message #1770554 is a reply to message #1770552] |
Mon, 14 August 2017 10:01 |
Jonah Graham
Messages: 416
Registered: June 2014 |
Senior Member |
|
|
Hi Anton,
Glad I helped.
Quote:So I think I will have to either recompile gdb to show older version or recompile eclipse to give only old features to even the new version of gdb.
What I couldn't understand from the trace you provided earlier is where exactly things went wrong.
If it is setting the file after doing the target remote, I am not sure how to resolve that with the standard Eclipse CDT launches as they do that target connection first, then set the file.
Are you using GDB Hardware Debugging (or C/C++ Remote Application). If you haven't used the GDB Hardware Debugging, I recommend it as it allows more customisation on launch/etc. In particular, if you provide the symbol file parameter in the configuration, that will mean the symbol table is loaded before the target remote is done:
695,972 14symbol-file <path to>/HelloRemote
695,972 &"symbol-file <path to>/HelloRemote\n"
695,972 ~"Reading symbols from <path to>/HelloRemote..\
."
695,973 ~"done.\n"
695,976 14^done
695,976 (gdb)
695,976 &"\n"
695,976 ^done
695,976 (gdb)
695,977 15-target-select remote localhost:10000
695,991 16-list-thread-groups
695,994 =tsv-created,name="trace_timestamp",initial="0"\n
695,994 =thread-group-started,id="i1",pid="26404"
This is the UI I am referring to:
|
|
| | | |
| Re: Crosscompiled debuging. [message #1771069 is a reply to message #1770698] |
Mon, 21 August 2017 16:03 |
Anton Krug
Messages: 9
Registered: August 2017 |
Junior Member |
|
|
Hi Jonah,
In the beginning, I completely misunderstood what could be the cause of the problem and be asking wrong questions, but it got me to the journey where I made some progress. There were 3 different overlapping problems:
1) I was using the wrong configuration, the GDB Hardware Debug didn't solve it, but made me more focused on the differences between the configurations and was trying all of them. The correct configuration which worked for me was the "C/C++ Remote Application" with the "GDB (DSF) Manual Remote Debugging" launcher. Which is not the default one in the Eclipse. The automatic one is the default, which looks like is meant to a Linux based system or something where you can start the gdbserver yourself, which is different from the setup I'm using.
2) With Eclipse 4.4 (CDT 8.6) there was the bug you linked to me and the toolchain gdb 7.12 got detected as 7.1 which then caused a different problem. This got fixed around Eclipse 4.5 I think.
3) The Eclipse 4.4 (and newer) with gdb 7.1 has the "delete breakpoint after creating" bug. As you mentioned before there is line what is unsupported, the 7.1 is too old anyway. What is interesting that I found few bug reports which share similarities with my issue, they look as solved, but my symptoms still are present. Not that it matters, on newer Eclipse and recent gdb this is not an issue. I will just recompile the 7.12 toolchain to pretend to be 7.9 for my Eclipse 4.4 setup. And even that will not be necessary under the newer Eclipse. When the legacy launcher has been used no issues no matter what gdb version are shown, but as you said before legacy will be removed. I'm not sure if the bug I experience is one of these, but they sound similar to my issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=435144
https://bugs.eclipse.org/bugs/show_bug.cgi?id=431986
https://bugs.eclipse.org/bugs/show_bug.cgi?id=442394
I think few times I managed to setup the breakpoint without deleting, so it was not deleting 100% of them.
If older Eclipse and older gdbs are avoided there should not be any issues.
Anton.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 19:45:43 GMT 2024
Powered by FUDForum. Page generated in 0.02820 seconds |
] 
Search
Help
Register
Login
Home
