Re: Missing Debug Info

[Brian Duffy <brduffy gmail com>]

Thanks so much for that explanation Dodji,

I have gotten a little feedback from the vala mailing list as well now. It was made clear to me that I could call clutter_actor_get_width(r) from within the debugger to access that particular property so I guess calling accessor methods is another approach to use. What still confuses me some is that I can print the value of the property out to the console with vala's printf statement. It seems to me that there must be some way to get the debugger (gdb) to grock what the vala printf statement does without having to rewrite the valac compiler. It looks like one user did some work on a gdb patch that might address this. I'll need to look into it.

Thanks again

Brian

On Sun, Dec 18, 2011 at 6:21 AM, Dodji Seketeli <dodji seketeli org> wrote:

Hello Brian,

Brian Duffy <brduffy gmail com> a écrit:

> First of all, I'm new to Vala/Clutter and Nemiver.

You are welcome on this mailing list.

> I'm posting here because I'm having a debugging problem but that does
> not mean it is Nemiver's fault. Still, I get no response from Clutter
> or Vala mailing lists so I'm hoping someone uses Nemiver to debug
> vala/clutter programs.

I see.  Please bear in mind that Vala, by design, doesn't generate debug
information about its type system.  Rather, it generate C code that is
in turn compiled by a C compiler.  One of the problems with this
approach is what I'd generally call "less than optimal integration with
the rest of the toolchain".

One part of the toolchain that needs special integration care is the
part that deals with debug info generation.

For instance, in C, the only types a user can create are structs.  So
your instances of classes and implementations of interfaces in Vala that
are meaningful to you become a set of structs underneath, that are not
necessarily as meaningful as the abstractions you put together in Vala
in the first place.

That is usually not a problem as compilers routinely "unroll" users'
abstractions, to make data structures better fit with the underlying
system.  It can be a problem, though, when those unrolled abstractions
are presented back to you when you are debugging your own code.  At that
point, there is an impedance mismatch between the source code you wrote
and what the debugger is presenting you.

The good way to "fix" this, or rather to prevent it from happening in
the first place is to have the compiler generate binaries directly (so
that it can have an opportunity to generate the debug information that
accurately describes the abstractions that the language allows), rather
that generating C code that is later compiled by a C compiler.  This is
the tough lesson that implementors of languages like C++, Ada, D,
Objective-C, etc, all learned with time.  This is one of the reasons why
you'll see these languages are implemented as front-ends of a greater
compiler system that helps in taking care about things like debug info.

History shows that, most of the time, implementors of new languages do
their experiments in their own "circles", rather than integrating with
existing compiler systems and communities to come up with something that
integrates well with a native toolchain.  And some of them end up
integrating their language implementation with a greater compiler
system.

> Specifically, I am trying to play with the Vala clutter-demo example
> from their website.  The example runs fine when I execute it. I am
> compiling it with valac -g --pkg clutter-1.0 --save-temps. I notice
> when I load the executable in Nemiver and set a break point that I can
> read variables defined in the Vala language such as loop counter
> iterators with success. The problem I am having is that reading the
> properties of clutter objects in the debugger is not working as I had
> hoped.

I see.

> For instance if a Rectangle r is defined then it shows up in the
> context window as r and its type is defined as ClutterRectangle * and
> it has an hexadecimal value. I can't expand on the variable and if I
> highlight r.width in the code and try to inspect the variable then I
> get nothing in return.

Right.  Exactly the impedance mismatch I was talking about.  When you
write "Rectangle r", I guess underneath, valac generates a pointer to a
C struct that is ClutterRectangle, whereas you, as a code writer, just
wrote Rectangle r.

So when you ask the debugger to inspect r.width, there is nothing it can
do because nothing in the binary tells it that a type Rectangle exists,
and that it has a 'r' member, because no accurate debug info is
generated for that.  The only debug info generated is about
ClutterRectangle pointers, because that is what the C compiler knows
about.

You are taken back to 15 years ago, when, e.g, most C++ compilers where
implemented as C pre-processors, like what valac is today.

> Is this as good as it gets for debugging Vala programs or am I doing
> something horribly wrong? Any thoughts would be welcome.

Unfortunately I think it is as good as it can get, until the valac
implementation is changed to something that can insert accurate debug
information in the generated binaries.

I hope this helps.

--
               Dodji

_______________________________________________
nemiver-list mailing list
nemiver-list gnome org
http://mail.gnome.org/mailman/listinfo/nemiver-list

-- 
Duff