Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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


Back to the top