I'm on Ubuntu 18.04, codeclap 9.0.1.
I'm trying to view the glibc sources inside of codeclap.
I compile a simple hello world program like so:
Following the advice from this stackoverflow postI have performed:
As there is no '.gdbinit' to tell codeclap about this, I still see assembly inside of codeclap. Is there some way to overcome this?
Thanks.
I'm trying to view the glibc sources inside of codeclap.
I compile a simple hello world program like so:
1 | clang -g -fuse-ld=lld test.c -o test |
Following the advice from this stackoverflow postI have performed:
1 | sudo apt install libc6-dbg glibc-source; tar xvf /usr/src/glibc2.6.tar.xz |
As there is no '.gdbinit' to tell codeclap about this, I still see assembly inside of codeclap. Is there some way to overcome this?
Thanks.
Edited by Ryan
on
Reason: Initial post
Good to hear that you found a way to work around this.
I think 0.9.1 should have the necessary capabilities to do what you want but it will be highly inconvenient because none of this is remembered across restarts.
However 0.9.5 should be available at the end of next saturday which will persist debug information paths and source paths across restarts.
In general what you need is available from the "Modules" window which is not shown by default.
1.
First step is to locate the debug information from the corresponding -dbg package (somewhere in /usr/lib/debug i think) using the option "Load debug information" from the context menu. In 0.9.5 you will also have the option to "remap" a directory or one of its parents in a recursive way. This step is probably not necessary with gdb because the object file has an attribute "gnu_debuglink" which codeclap currently does not read.
2.
After that codeclap should detect all the missing source files, at the latest when trying to step into one of the functions. Now either double click the line from step 1 in the modules panel or choose "Locate source files" from the context menu. Here it is basically the same. You can either locate a single file (right click the line with the file) or remap a whole directory (broken in 0.9.1 on Linux because of some directory separator mismatches).
This should get you the source and debug information. However beware that because of the optimizations in these shipped libraries showing values from variables and such is probably rather unreliable.
I am also starting to collect a few common issues or questions in order to create a bit of documentation after the release of 0.9.8 (on the way to 1.0 when the interface is mostly final). This is probably one of the topics that will fit in there (with screenshots or a few small videos/animations).
I think 0.9.1 should have the necessary capabilities to do what you want but it will be highly inconvenient because none of this is remembered across restarts.
However 0.9.5 should be available at the end of next saturday which will persist debug information paths and source paths across restarts.
In general what you need is available from the "Modules" window which is not shown by default.
1.
First step is to locate the debug information from the corresponding -dbg package (somewhere in /usr/lib/debug i think) using the option "Load debug information" from the context menu. In 0.9.5 you will also have the option to "remap" a directory or one of its parents in a recursive way. This step is probably not necessary with gdb because the object file has an attribute "gnu_debuglink" which codeclap currently does not read.
2.
After that codeclap should detect all the missing source files, at the latest when trying to step into one of the functions. Now either double click the line from step 1 in the modules panel or choose "Locate source files" from the context menu. Here it is basically the same. You can either locate a single file (right click the line with the file) or remap a whole directory (broken in 0.9.1 on Linux because of some directory separator mismatches).
This should get you the source and debug information. However beware that because of the optimizations in these shipped libraries showing values from variables and such is probably rather unreliable.
I am also starting to collect a few common issues or questions in order to create a bit of documentation after the release of 0.9.8 (on the way to 1.0 when the interface is mostly final). This is probably one of the topics that will fit in there (with screenshots or a few small videos/animations).