Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Anton Krug is currently offline Anton KrugFriend
Messages: 5
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 Go to previous messageGo to next message
Jonah Graham is currently offline Jonah GrahamFriend
Messages: 399
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 #1770552 is a reply to message #1770545] Mon, 14 August 2017 09:34 Go to previous messageGo to next message
Anton Krug is currently offline Anton KrugFriend
Messages: 5
Registered: August 2017
Junior Member
Hi Jonah,

I think you answered me everything and explained exactly what I needed, thank you very much. I maybe was not sure what exactly to ask because I was not 100% sure what was going on. Now my understanding of the problem is:

Eclipse showing the -version is just for user friendliness (probably adding verbosity to cases like this to show actually what version was used), but there is separate version detection which actually detects features capabilities of the gdb <-> gdbserver.
That the vast majority of uses is when you are compiling the gdb and gdbserver from the same source and you are running the same version on both sides. In my rare case, the gdbserver is older (and I don't have access to change it) and the gdb version is newer. This leads to eclipse guessing features higher than my gdbserver can deliver and then causing all other problems.

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.

As follow up question, is there a way to query gdbserver version when the gdb is connected to it (my only way of interaction with the gdbserver). I have seen a handful of commands which gdb can send to gdbserver, but didn't see a way to query its version. In worst case I will guess version 6.8 or lower.

Thank you very much for all the links, they are exactly pointing to the logic I was not even sure if it exists.

Best regards.
Re: Crosscompiled debuging. [message #1770554 is a reply to message #1770552] Mon, 14 August 2017 10:01 Go to previous messageGo to next message
Jonah Graham is currently offline Jonah GrahamFriend
Messages: 399
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:
index.php/fa/30365/0/
Re: Crosscompiled debuging. [message #1770675 is a reply to message #1770554] Wed, 16 August 2017 08:07 Go to previous messageGo to next message
Anton Krug is currently offline Anton KrugFriend
Messages: 5
Registered: August 2017
Junior Member
I tried the GDB Hardware Debuging but not with much success. In the end they not succeeded because the arch was not set right. After the correct arch was set then they connect, but the breakpoints set from UI will not propagate to gdb, only the ones which you type by hand in the console are active. In mean time I recompiled the gdb to show version 7.0 instead and there was no improvement on my issue.

I was in the mindset that the new version is cause of this issues, but looks like they are present. Even when I converted workspace and used the same configuration the newer eclipse ignores the "C/C++ Application" file and the "Source Lookup Path" folders so they are not sent to gdb for some reason, and probably other issues cascade.

I'm mostly using the "C/C++ Attach to Application" because the "Remote applicacation" tries to start the gdbserver by it's own and use the serial/telnet or ssh to get there. But I don't have Linux nor any of these services available, the gdbserver is already running for me so the eclipse doesn't have to start it.
Re: Crosscompiled debuging. [message #1770687 is a reply to message #1770675] Wed, 16 August 2017 09:20 Go to previous messageGo to next message
Jonah Graham is currently offline Jonah GrahamFriend
Messages: 399
Registered: June 2014
Senior Member
The description you are describing is exactly what GDB Hardware Debugging is for. However I can't quite follow exactly what went wrong when you tried that. Chip/board makers often ship additional Eclipse plug-ins that further customize the debugging experience to work with their boards/tools. Are you representing a manufacturer? I know a lot of companies are experimenting with riscv to figure out where they fit in the future landscape.
Re: Crosscompiled debuging. [message #1770698 is a reply to message #1770687] Wed, 16 August 2017 10:48 Go to previous messageGo to next message
Anton Krug is currently offline Anton KrugFriend
Messages: 5
Registered: August 2017
Junior Member
Hi Jonah,

In the end I think I resolved the issue, it was slightly something else than what I was expecting, but your guidance helped me a lot! Give me some time I will test it more to be able to replicate it properly so I can then confidently post what was the cause so we then close this thread as solved.

Thank you very much.

Anton.
Re: Crosscompiled debuging. [message #1771069 is a reply to message #1770698] Mon, 21 August 2017 16:03 Go to previous message
Anton Krug is currently offline Anton KrugFriend
Messages: 5
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.

Previous Topic:Embedded development ARM x86
Next Topic:How to add preprocessor symbol in C++ Arduino Project
Goto Forum:
  


Current Time: Sat Dec 16 09:24:13 GMT 2017

Powered by FUDForum. Page generated in 0.01559 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software