Someone is trying to debug ATS code using DWARF?

Google Group
1

My guess is that the only debugging available in the final binary is what’s put there by the C compiler, not the ats compiler.> On Mar 7, 2015, at 4:44 AM, Kiwamu Okabe kiw...@debian.or.jp wrote:

Hi all,

OCaml is able to debug compiled binary using gdb
that reads DWARF in the binary.
Then, I hope ATS2 compiler create binary execution with DWARF.

Someone is trying to debug ATS code using DWARF?

Best regards,

Kiwamu Okabe at METASEPI DESIGN

–
You received this message because you are subscribed to the Google Groups “ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAEvX6dmU6A1cC_nmgyv7m5j50gwA8Chf-aR7hPf%2BNB3cnHRdZw%40mail.gmail.com.

2

I have no experience with DWARF.

The C code generated from ATS source contains a lot of location
information on the source code. If you pass --gline to patsopt, then
you can get more.

The biggest hurdle as I see it lies in the handling of templates in ATS.
Due to template instantiation, it can currently be very difficult to know
how exactly the C code gets generated. Regardless using DWARF or not,
this is something that needs to be addressed.On Saturday, March 7, 2015 at 8:27:22 AM UTC-5, Kiwamu Okabe wrote:

Hi Shea,

On Sat, Mar 7, 2015 at 10:21 PM, Shea Levy <sh...@shealevy.com <javascript:>> wrote:

My guess is that the only debugging available in the final binary is
what’s put there by the C compiler, not the ats compiler.

Yes, right.

My idea is replacing the DWARF of C compiler with a DWARF of ATS.
Is it impossible?

Thank’s,

Kiwamu Okabe at METASEPI DESIGN

3

I have no experience with DWARF.

The C code generated from ATS source contains a lot of location
information on the source code. If you pass --gline to patsopt, then
you can get more.

The biggest hurdle as I see it lies in the handling of templates in ATS.
Due to template instantiation, it can currently be very difficult to know
how exactly the C code gets generated. Regardless using DWARF or not,
this is something that needs to be addressed.

Some debugging ideas:

  1. With Felix, I can “just” read the generated C++ code.
    Others can’t but I can, because of the styalised symbol naming
    and comments.

My tool allows me to modify the C++ code with printf() statements
and rebuild without re-running the translator (but preserving all
the linkage instructions etc).

  1. ATS should have a way to insert debugging into the ATS
    code by the ATS programmer. This includes something like

    nop “string”

which does nothing but emits an instruction the compiler THINKS
does something important. A variant

debug "string";

is the same but can turn into a printf (which also tells the location
on both the ATS and C code).

  1. A way to automatically instrument functions: add the
    debug strings to the start of every function. Slows stuff down
    a bit.

  2. My current tracing idea is to turn special logging/debugging
    commands like those above into writes on a UDP socket.
    This allows to connect a real time monitoring tool. That in turn
    could be connected to a TCP socket running HTTP so you could
    get some idea what’s happening using a web browser.

None of these ideas are complete solutions. ATS like Felix
generates code in C/C++ which can crash due to corruption
from invalid pointers. Personally I find reading the code
and logical reasoning far better than debuggers … debuggers
are a last resort because they really can’t help much with
corruption. Valgrind is similar, it tries. I find gdb and valgrind either
find your bug in 10 seconds flat or they’re useless.

john skaller
ska...@users.sourceforge.net
http://felix-lang.org