A couple of questions/issues

May 31, 2011 at 12:43 AM

Hi Cristian,

First of all thanks for making this amazing project open source!

I've made a checkout of the sources a couple of days ago(rev 62481) and I've been
playing around with the project. I'm interested to use the debugger for C++ and
especially for D - I'm learning the language and there doesn't seem to be much
alternative when it comes to debuggers in the Linux world; I've tried GDB 7.2 with
D support but it's completely unusable when it comes to debug code compiled for
D2 with the latest dmd compiler(or at least it was for me).
I would like to also integrate the debugger into Eclipse IDE, for both C++ and D.

The build process went pretty smooth except for a couple of things I'll try to outline below.
I have also some questions/misunderstandings and it would be great to have some answers,
if possible, from you. I'll just get to the point.

My system:

- Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux
- gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
- DMD32 D Compiler v2.053
- I've installed all the required libraries as outlined in the README

1. I've encountered a compilation error in the elfz project:

core_file.cpp: In member function ‘void ELF::CoreFile::read_segment(const ELF::ProgramHeader&)’:
core_file.cpp:104:9: error: narrowing conversion of ‘((const ELF::ProgramHeader*)phdr)->ELF::ProgramHeader::memsz()’ from ‘Elf32_Xword’ to ‘size_t’ inside { }
core_file.cpp:104:9: error: narrowing conversion of ‘((const ELF::ProgramHeader*)phdr)->ELF::ProgramHeader::filesz()’ from ‘Elf32_Xword’ to ‘size_t’ inside { }

I think this thread from StackOverflow provides a pretty good outline to the problem encountered and
also the obvious solution(I'm not very proficient with the new C++0X standard ... but I'm learning).
I've made a patch file but unfortunately there's no option to attach a file so I'll just embed it below(sorry about that, it looks messy I know)

Index: elfz/core_file.cpp
===================================================================
--- elfz/core_file.cpp	(revision 62528)
+++ elfz/core_file.cpp	(working copy)
@@ -100,7 +100,7 @@
     {
         Segment seg =
         {
-            phdr.offset(), phdr.memsz(), phdr.filesz(), phdr.flags()
+            phdr.offset(), static_cast<size_t>(phdr.memsz()), static_cast<size_t>(phdr.filesz()), phdr.flags()
         };
         ElfW(Addr) vaddr = phdr.vaddr();


2. I had also compilation/linking errors for a couple of other projects(libdwarf, libudis86)
related to missing include and library paths. That happens in relation to the third party libraries
in the zero debugger if one does not have the third party libraries installed on the system and
builds them as part of the debugger's build; the build system does not look for the headers or
the libraries in the third_party_libs folder it just expects them to be present on the system.
That I fixed modifying the zdk/make/Common.mak.in file. Patch pasted below:
Index: zdk/make/Common.mak.in
===================================================================
--- zdk/make/Common.mak.in	(revision 62528)
+++ zdk/make/Common.mak.in	(working copy)
@@ -34,6 +34,8 @@
 
 #where to output libs, binaries, and plug-ins
 LIB_PATH=$(TOP)/lib/
+#additional libraries, that is third party libs
+ADD_LIB_PATH=$(TOP)/local/lib
 BIN_PATH=$(TOP)/bin/
 PLUGIN_PATH=$(TOP)/plugin/
 
@@ -134,9 +136,12 @@
 
 #LDLIBS+=-ltcmalloc
 LDFLAGS+=-L$(LIB_PATH)
+LDFLAGS+=-L$(ADD_LIB_PATH)
 LDFLAGS+=-L/usr/local/$(LIBDIR)
 
 BOOST_INCLUDE_PATH=@BOOST_CPPFLAGS@
+#additional include path, that is for third party libraries
+ADD_INCLUDE_PATH=-I$(TOP)/local/include
 
 #set default debugging format
 ifeq ($(DEBUG_FORMAT),)
@@ -149,7 +154,8 @@
 	$(BOOST_INCLUDE_PATH) \
 	$(STL_INCLUDE_PATH)	\
 	-I$(TOP) \
-	-I$(TOP)/zdk/include
+	-I$(TOP)/zdk/include \
+	$(ADD_INCLUDE_PATH)
 
 #Intel Compiler?
 ifeq ($(CXX),$(ICC))


3. I had a hard time building the UI and that was mainly due to the gtkmm/gtksourceviewmm libraries.
I've installed the required ones as in the README but the UI plugin failed compilation most of the
times with the following error:

code_view.cpp
In file included from code_view.h:23:0,
                 from code_view_common.h:18,
                 from code_view.cpp:41:
gtkmm/text.h:179:22: error: ‘SourceLanguagesManager’ was not declared in this scope
gtkmm/text.h:179:44: error: template argument 1 is invalid

That seemed to be caused by the missing definitions of the GTKMM_2 and GTKSVMM_VERSION. I just
commented out the tests involving those(text.h and text.cpp) and I managed to build the UI plugin. I'm not sure about
the root cause of that(I'm still looking into it) but I guess it might be a misconfiguration of
GTK libraries on my part(I'm not very familiar with GTK); here follows the list of GTK related
libraries used by the UI plugin I built:
    libgtksourceviewmm-2.0.so.2 => /usr/lib/libgtksourceviewmm-2.0.so.2 (0x005b3000)
        libgtkhtml-3.14.so.19 => /usr/lib/libgtkhtml-3.14.so.19 (0x00669000)
        libgtkmm-2.4.so.1 => /usr/lib/libgtkmm-2.4.so.1 (0x00fee000)
        libgtksourceview-1.0.so.0 => /usr/lib/libgtksourceview-1.0.so.0 (0x007c6000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x0134a000)
        libgtksourceview-2.0.so.0 => /usr/lib/libgtksourceview-2.0.so.0 (0x00e7c000)
       
I haven't tested it yet as right now I'm mostly interested with the CLI of the debugger which brings
me to my next point.

4. The --ui-disable command line flag tricked me a bit. I was expecting it would be parsed by the debugger shell
but it turns out that is parsed by the UI plugin itself. So I wasn't able to use the debugger without
having the UI plugin built, which in my case was quite of a hassle as detailed above. This seems a bit odd
to me that to be able to run the CLI I have to have the UI plugin loaded by the debugger first and then
its usage be denied. Would it be possible to have the CLI without any interference whatsoever of the UI?
Maybe even have a build option to skip the UI plugin build if desired?

5. I will integrate the debugger in Eclipse to test drive it's usage with D and Eclipse DDT.
What's the level of support for debugging D executable at this moment? What would be the TODO list in
that area as I was thinking maybe I could help? Do you have any design notes on the lines of the
ones on your site regarding D support?

Thanks

Marius

Nov 11, 2011 at 6:15 PM

Hi  Marius,

First of all let me apologize for the huge delay in getting back to you. I meant to reply, then got distracted with silly things such as full time job, family and all that. Promise to get better at answering questions in the future.

I will try to answer some of your points:

1) My dev machine is 64bit, I promise to be more careful in the future and also compile / test in 32 bit. I used to do lots of 32/64 testing on 10 Linux distros or so back when I was trying to launch Zero BUGS as a startup, but now that I gave up on that and made it open source I am more frugal.

I am a bit puzzled that Elf32_Xword and size_t are not the same size in 32 bit. I will investigate this weekend.

2) The intent was indeed to have the linker look into third_party_libs (even if the user has those on the system, I WANT to link with the specific version I tested with). Looks like a BUG and your suggested fix looks good. 

3) Yeah, moving away from gtksourceview-1.0 was a pain that I kept delaying -- I hope my change from late last night addresses the issue.

Come to think of that, I think I should change my configure script to look for gtksourceview-2.0 first, and only if not found to fail over to gtksourceview-1.0. Or maybe even drop 1.0 altogether.

4) The reason --ui-disable is parsed by the GUI plugin is that I tried to create a component-based architecture where the engine does not need to know about implementation details of the plugin. Each plugin gets a chance to look at the command line and grab the switches that it recognizes.

If any command line switches are left unconsumed, there should be a warning about unrecognized command line options.

If the GUI does not build, then there's no UI anyway.

5) My recollection is that Eclipse talks to GDB via the Debugger Machine Interface (http://www.linux-foundation.org/en/DMI). I started researching that back in 2007 then I dropped it.

One of the plugins in the Zero Debugger is a Python interpreter that has access to internal C++ interfaces (via boost::python). The idea is to allow users to quickly script the debugger, or build extensions to it in Python.

dmi.py (it is in the source tree under the python directory) was my attempt to implement a DMI-conforming command line interface for the debugger, so that I could talk to it from Eclipse.

I have not tested with D recently but unless Walter did something to his DWARF-outputting code it should work great. For most parts my debugger is language-agnostic. One language-specific part that I always wanted to re-architect is the expression interpreter, which is built around C/C++ syntax. 

 

Sorry again for the horrible response time. If you have the time and desire to contribute to this project I could give you check-in access.

Thanks,

Cristian

 

 

 

 

 

 

Nov 12, 2011 at 8:35 PM

Hi Cristian,

No need for apologies and thanks for answering ... I was kind of giving up about receiving any feedback :).

I understand how it is to get "distracted with silly things such as full time job, family and all that" ... I  thought

that I will have the initial integration of the debugger with Eclipse in 1 - 2 months top, but unfortunately I'm still at

the "trying out and looking for a proper software integration" phase. Anyway your answer and

the fact that you're interested in this kind of integration will give me some steam :).

 

I'm using the debugger on daily basis for anything related to D stuff(nothing very involved right now) and it

works great but I have not updated the source code in a while ... I'll make a checkout of the latest source tree

and see how things go related to the gtksourceview.

About the UI plugin of course you're absolutely right and I've seen it works as you describe a couple of days after

I posted the messages - right now I don't have the UI plugin installed in the zero lib folder and when started

the debugger outputs "Detecting plugins...*** Option not understood: --ui-disable" ... so everything is clear on that

front right now.

Indeed Eclipse uses the MI protocol to talk to GDB but I took another approach initially as implementing the

MI for zero seemed a bit daunting and I missed completely the python implementation. I'll definetly take a look at

the dmi.py. My initial approach was based on the Eclipse Helios GDB DSF(Debugger Services Framework)

implementation, trying to make a one-to-one mapping through DSF to the debugger's commands.

 

It would be great if I could contribute to the project in any way but to be honest I'm a bit lost in regards

to what exactly I could do as a first step so please let me know what do you think would be a good starting point.

Thanks,

Marius