RE: [dsdp-tcf-dev] ISymbols, scope information and symbol addresses

["Tarassov, Eugene" <eugene.tarassov@xxxxxxxxxxxxx>]

Hi Torleif,

At first, I should say that Symbols service specifications are
preliminary draft and open for discussions. Comments and proposals are
welcome.

> Is this interface meant to provide scope information as well as symbol
information?

If by scope information you mean ability to search according to
particular language visibility rules, then the answer is "no".

Actually, the service does not provide any search methods. Current
thinking is that clients look up symbols using other services, while
Symbols service responsibilities are reduced to retrieving symbol
properties and children. One way to search for a symbol is to evaluate
an expression using Expressions service. For example, expression like
"namespace::class::function" could be evaluated using Expressions
service, and should return function symbol as the expression type, then
you can use Symbols service to get all attributes of the function. Since
expressions are evaluated in a particular context (PC, stack frame,
etc.), Expressions service can search symbols according to expression
language visibility rules, starting from the scope of the given context.

> Should one consider scopes to be symbols?

Probably. Functions and classes are symbols already, compilation units,
name spaces, lexical blocks can be easily exposed as symbols too.

> From the ISymbols interface, I assume that it does not present only
that static view of the contents of an objectfile but is based on
implementers having the ability to query the CPU for stack pointer,
program counter, register contents and so on. Am I correct in this
conjecture?

ISymbols interface provides only static information. Ability to query
the CPU for stack pointer, etc, is exposed through other APIs, mostly
IExpressions interface.

> ... how would one be able to get the value of symbols with this
interface if the address in the symbol information is not an absolute
address but use some addressing mode, or if the symbol was optimized and
its address varies with program counter?

Yes, symbol address is dynamic information and it depends on program
counter, stack frame, process ID, etc. Lookup and evaluation of symbols
in a given context is provided by Expressions service. You can use
Expressions service to evaluate an address. For example, if you have a
local variable "int x;", you can evaluate expression "&x" on a
particular stack frame to get address of x.

Regards,
Eugene

-----Original Message-----
From: dsdp-tcf-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Sandnes, Torleif
Sent: Tuesday, November 10, 2009 5:31 AM
To: DSDP TCF dev list
Subject: [dsdp-tcf-dev] ISymbols, scope information and symbol addresses

Hi.

I have looked at the ISymbols interface defined in 

http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/plugins/org
.eclipse.tm.tcf.core/src/org/eclipse/tm/tcf/services/ISymbols.java and
have some questions concerning this:

1.
Is this interface meant to provide scope information as well as symbol
information? 

I see that it can provide scope information to some extent, given the
symbol context hierarchy. In some cases, however, one may need to look
up a symbol within a given scope. For example, one might look up the
current scope from the program counter and get a scope Id and use this
together with a symbol name to get the correct symbol context.

Should one consider scopes to be symbols? Will, for example, C++
namespaces be symbols? Or, for object files linked together from several
compilation units, will each compilation unit constitute a symbol?

If one were to add scope information lookup, would it be natural to add
it as a part of ISymbols, or would it be a separate service. Should one
consider Scopes to be Symbols?

Would it be feasible to have a method to look up scopes given some sort
of standardized scope string? i.e. For the function getNumber() in class
Data in file/compilationunit data.cpp, this string might have been
something like: data.cpp::Data::getNumber

2.
>From the ISymbols interface, I assume that it does not present only
that static view of the contents of an objectfile but is based on
implementers having the ability to query the CPU for stack pointer,
program counter, register contents and so on. Am I correct in this
conjecture?

If not, how would one be able to get the value of symbols with this
interface if the address in the symbol information is not an absolute
address but use some addressing mode, or if the symbol was optimized and
its address varies with program counter?

Thanks,

Torleif Sandnes
Atmel Norway
_______________________________________________
dsdp-tcf-dev mailing list
dsdp-tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev