ASIS?

ASIS?

[parthaspanda22]

If one were to need an API to fulfill all requirements by a Debugger,
Source Browser and
a Syntax-aware editor from the IDE, then would ASIS be it?

Can a compilation environment just provide an ASIS interface for third-
party
debuggers, source browsers and syntax-aware editors to plug-in and
work well?

Is a C interface available?

Sincerely.

Re: ASIS?

[Ludovic Brenta]

parthaspanda22@gmail.com writes:
> If one were to need an API to fulfill all requirements by a
> Debugger, Source Browser and a Syntax-aware editor from the IDE,
> then would ASIS be it?

The debugger does not need all the capabilities of ASIS; only line
numbers and type descriptions.  That's what GDB gets from the object
files generated by GNAT with -g.  The editor does not need all the
capabilities of ASIS.  For example, emacs, GPS and Eclipse all do
syntax highlighting without ASIS.

The source browser is probably the one component that would benefit
from ASIS the most; however an alternative is gnatfind which uses the
.ali files generated by GNAT for cross-references.  GPS uses gnatfind,
not ASIS, for this functionality.  In contrast, adabrowse generates an
HTML description of a program, with hyperlinks, using ASIS.

However, the answer to your question is probably yes: ASIS would
provide all the information needed, and more, to the debugger, browser
and editor, in a single interface.

> Can a compilation environment just provide an ASIS interface for
> third-party debuggers, source browsers and syntax-aware editors to
> plug-in and work well?

Yes but the word "just" is often the sign of a mistake and rings an
alarm bell in my head whenever I see or hear it :) In this case, it
hides these problems:

1) The complexity of providing the ASIS interface and that of using it
   from all tools.

2) The ASIS interface can only be provided on legal, compiling program
   text.  Any program with compile-time errors in it would be
   impossible to browse (using the source browser) and the editor
   would have to be particularly smart in deciding when to call the
   compiler to regerenate the ASIS information.

3) In the worst of cases, regenerating the ASIS data can cause massive
   recompilations and be too slow for interactive use.

> Is a C interface available?

Not that I know.  Why do you ask?

-- 
Ludovic Brenta.

Re: ASIS?

[parthaspanda22]

>
> 2) The ASIS interface can only be provided on legal, compiling program
>    text.  Any program with compile-time errors in it would be
>    impossible to browse (using the source browser) and the editor
>    would have to be particularly smart in deciding when to call the
>    compiler to regerenate the ASIS information.

There is a solution to this:

1) If a file compiles successfully, then use ASIS.
2) If a file compiles with errors then first use ASIS and then do
grep.

>
> 3) In the worst of cases, regenerating the ASIS data can cause massive
>    recompilations and be too slow for interactive use.

The key to this is how thin a layer ASIS is. Regenerating of "ASIS
data"
sounds like data transformation: from an AST to ASIS objects.
Perhaps, this can be avoided.

>
> > Is a C interface available?
>
> Not that I know.  Why do you ask?

There is some mention of JSIS(Java) but the link leads
to an unrelated site. A C interface would be very handy
for a C implementation.

Thanks.

Re: ASIS?

[parthaspanda22]

On Oct 26, 4:58 pm, parthaspand...@gmail.com wrote:
> > 2) The ASIS interface can only be provided on legal, compiling program
> >    text.  Any program with compile-time errors in it would be
> >    impossible to browse (using the source browser) and the editor
> >    would have to be particularly smart in deciding when to call the
> >    compiler to regerenate the ASIS information.
>
> There is a solution to this:
>
> 1) If a file compiles successfully, then use ASIS.
> 2) If a file compiles with errors then first use ASIS and then do
> grep.
>

I will elaborate on this a little more.
If, for instance, a source browser wants to get to
the definition of a symbol, then it doesnt matter
that there was a compilation error. The first (erroneous)
definition site would be emitted as an ASIS
record. However, if the type of an object
is required to be navigated to, then,
we need compilation artefacts(an ASIS binding
to an AST or some IL).

Re: ASIS?

[Niklas Holsti]

Ludovic Brenta wrote:
> parthaspanda22@gmail.com writes:
> 
>>If one were to need an API to fulfill all requirements by a
>>Debugger, Source Browser and a Syntax-aware editor from the IDE,
>>then would ASIS be it?
> 
> 
> The debugger does not need all the capabilities of ASIS; only line
> numbers and type descriptions.

This seems insufficient for debugging, see below.

> However, the answer to your question is probably yes: ASIS would
> provide all the information needed, and more, to the debugger, browser
> and editor, in a single interface.

I thought ASIS only has "high-level" information prior to the 
target-dependent object-code generation and linking. I think the 
debugger will need the link map, information about the stack frame 
layouts, record layouts, etc, which is not in the ASIS domain. Am I 
wrong?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: ASIS?

[parthaspanda22]

> I thought ASIS only has "high-level" information prior to the
> target-dependent object-code generation and linking. I think the
> debugger will need the link map, information about the stack frame
> layouts, record layouts, etc, which is not in the ASIS domain. Am I
> wrong?
>

1) link map:

    The missing part is in linking a relocatable address to a symbol
name
    and vice-versa.
    (The map file provides this feature).

    It isnt difficult to extend ASIS to emit a record that augments
    symbol information by providing a new field whose type is
    the target machine's `C' intptr(defined as an integral type
    wide enough to represent an address).

2) stack-frame

    A lot of the information about stack are constants(e.g. the bias,
    the frame pointer register, the stack pointer register,
    the ABI) and these are hard-wired into the debugger.

3) record layouts

   Again, this is in the domain of the ABI, so no query needs to
   be made to ASIS to tell the record layout. There may be two
   variants though: packed and otherwise.

Re: ASIS?

[Niklas Holsti]

parthaspanda22@gmail.com wrote:
>>I thought ASIS only has "high-level" information prior to the
>>target-dependent object-code generation and linking. I think the
>>debugger will need the link map, information about the stack frame
>>layouts, record layouts, etc, which is not in the ASIS domain. Am I
>>wrong?
>>

You list various non-ASIS sources for the target- and 
link-map-specific information (below). Your original query was:

 > If one were to need an API to fulfill all requirements by
 > a Debugger, Source Browser and a Syntax-aware editor from
 > the IDE, then would ASIS be it?

It was the point "all requirements" to which I objected, but I must 
have misunderstood or not noticed your phrase "... from the IDE", 
which I now understand means "... apart from the information that 
can be had from other sources". But there are some executable 
program formats that include most of the ASIS-like information (for 
C code, at least), so for such executable formats a debugger would 
need no additional information from the IDE.

Anyway, your question and Ludovic's answer are sensible if one 
assumes that the "other sources" are some limited executable format 
such as ELF without DWARF.

> 1) link map:
...
>     (The map file provides this feature).

Yes, or the debugging info in the executable file.

> 2) stack-frame
> 
>     A lot of the information about stack are constants(e.g. the bias,
>     the frame pointer register, the stack pointer register,
>     the ABI) and these are hard-wired into the debugger.

Depends on the target. Some ABIs are very flexible and let the 
compiler do what it likes.

> 3) record layouts
> 
>    Again, this is in the domain of the ABI

Indeed, but as above it can be very flexible / unspecified.

So in addition to ASIS the debugger needs the target-specific 
information from some other source. That was my point, sorry if I 
added noise.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: ASIS?

[parthaspanda22]

> You list various non-ASIS sources for the target- and
> link-map-specific information (below). Your original query was:

How? By extending the ASIS spec to include map file information,
isnt the map file made redundant? Of course, it will
require multiple tools in the chain to write to
a common ASIS database.

>
>  > If one were to need an API to fulfill all requirements by
>  > a Debugger, Source Browser and a Syntax-aware editor from
>  > the IDE, then would ASIS be it?
>
> It was the point "all requirements" to which I objected, but I must
> have misunderstood or not noticed your phrase "... from the IDE",
> which I now understand means "... apart from the information that
> can be had from other sources". But there are some executable
> program formats that include most of the ASIS-like information (for
> C code, at least), so for such executable formats a debugger would
> need no additional information from the IDE.

It would be difficult to debug Generics or variant record types
unless there were a HLL interface. I expect ASIS to atleast
be able to address all Ada-specific syntactic sugar.
(There is a link to JSIS, but alas, it leads to
a useless site.)

>
> Anyway, your question and Ludovic's answer are sensible if one
> assumes that the "other sources" are some limited executable format
> such as ELF without DWARF.

Yes, a debugger must still need access to a working executable
for instrumentation. Machine-level debugging hasnt been
pursued that extensively by processors, so executable
instrumentation(i.e. SW debugging) is generally the norm.

>
> Yes, or the debugging info in the executable file.
>
> > 2) stack-frame
>
> >     A lot of the information about stack are constants(e.g. the bias,
> >     the frame pointer register, the stack pointer register,
> >     the ABI) and these are hard-wired into the debugger.
>
> Depends on the target. Some ABIs are very flexible and let the
> compiler do what it likes.

The scope of my research precludes going on a path where
the ABI is "flexible" but there are many examples of
your point, so I cant agree more.

Re: ASIS?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:4721db60$0$27834$39db0f71@news.song.fi...
...
> I thought ASIS only has "high-level" information prior to the
> target-dependent object-code generation and linking. I think the
> debugger will need the link map, information about the stack frame
> layouts, record layouts, etc, which is not in the ASIS domain. Am I
> wrong?

No. The Rationale for ASIS appendix of the ASIS standard states
"It is not a goal to support tools having dynamic run-time requirements
(e.g., symbolic debugger)."
It can't be any clearer than that.

(Sorry I can't give you a reference to the standard so you can see for
yourself, as the ASIS standard is copyright ISO and thus cannot be made
publicly available.)

                         Randy.

Re: ASIS?

[Niklas Holsti]

parthaspanda22@gmail.com wrote:
 >Niklas Holsti wrote:
>>You list various non-ASIS sources for the target- and
>>link-map-specific information (below). Your original query was:
> 
> 
> How? By extending the ASIS spec to include map file information,
> isnt the map file made redundant? Of course, it will
> require multiple tools in the chain to write to
> a common ASIS database.

This would bring in such a lot of new information that I would not 
call the result an "ASIS database". It would be a database that 
contains ASIS information *plus* other things. Maybe it should be 
called "ASIS-Plus" :-)

>>But there are some executable
>>program formats that include most of the ASIS-like information (for
>>C code, at least), so for such executable formats a debugger would
>>need no additional information from the IDE.
> 
> It would be difficult to debug Generics or variant record types
> unless there were a HLL interface.

Well, I know a C++ compiler in which the debug info in the 
executable (proprietary format) shows the whole class inheritance 
structure, including which calls in the code are virtual function 
calls and which are statically bound. There is also information on 
templates, in-lined calls, #defined macros, etc, and references to 
the source-code files, line numbers and column numbers where all 
those things are defined.

GNAT, too, puts a lot of information in the debug info. I haven't 
had occasion to look deeply into that, perhaps there is something 
about generics in it.

> I expect ASIS to atleast
> be able to address all Ada-specific syntactic sugar.

The debugger will still have the problem of mapping the Ada-level 
ASIS information to the machine-level program entities, including 
identifier mangling (eg. for instances of generics) and 
optimizations that delete variables and subprograms.

Your aim -- as I have grasped it -- is to combine the ASIS 
high-level information with low-level (machine-level) information 
from other sources (eg. the link map) and make it all accessible as 
an ASIS-like database structure. Good idea, but let's not call it 
just "ASIS".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .