Disambiguating object map variable names

[kpgriesser]

1 - Detailed description of problem or enhancement

It is possible to have duplicate names in the object map at the same level of hierarchy. The prototype implementation for ObjectMap::findVariable simply returns the first match from a std::multimap.

tactcomplabs#39 temporarily solves this for the cd command in order to demonstrate a possible solution where the user is prompted to select the variable. IMHO, it would be preferable to have the object map constructed in a way that ensures every variable is specified in a unique way and use a simple std::map instead of std::multimap.

For this issue, I propose
(1) We make sure we understand and can test all the possible cases where duplicate names can occur.
(2) we specify how to ensure unique and intuitive variable selection when the object map is created.

2 - Describe how to reproduce the issue

The reference code for the following examples can be found in the devel branch of git@github.com:tactcomplabs/sst-ext-tests.git

Example 1: ELI defined slot name conflict with component variables

sst-ext-tests/components/omni.h

class OMSimpleComponent : public SST::Component{
...
  SST_ELI_DOCUMENT_SUBCOMPONENT_SLOTS(
    { "function0",
      "generic function 0 (required)",
      "SST::ExtTest::OMSubComponentAPI" },
    { "function1",
      "generic function 1 (optional)",
      "SST::ExtTest::OMSubComponentAPI" },
...
private:
std::vector<uint8_t> function0 = { 10,20,30,40,50,60,70,80 }; // different type
OMSubComponentAPI* function1 = nullptr;                       // same type sans pointer

omni.cc

    SST_SER(p_omsimplecomp_function0_);
    SST_SER(function0);
    SST_SER(function1);

Interactive console session:

$ cd tests/core-debug
$ sst --interactive-start=0 omni.py -- --function0=dbgsst15.OMArrays --function1=dbgsst15.OMQueue

> cd c0
> ls
component_state_ = 3 (SST::BaseComponent::ComponentState)
function0/ (SST::ExtTest::OMArrays)
function0/ (std::__1::vector<unsigned char, std::__1::allocator<unsigned char>>)
function1/ (SST::ExtTest::OMQueue)
function1/ (SST::ExtTest::OMQueue)
my_info_/ ()
p_omsimplecomp_function0_/ (SST::ExtTest::OMArrays)

Example 2: Watchpoints on array elements

Simple array element names are simply the index of each element. Consider setting a watchpoint like:

watch 42 > 55

Is the right hand value of 55 an integer or an index? For that matter, the same applies to the left hand side.
We can see what is occuring in the current code using the verbose setting in the interactive console.

$ cd tests/core-debug
$ sst --interactive-start=0 omni.py -- --function0=dbgsst15.OMArrays --function1=dbgsst15.OMQueue

> verbose 0x10
> cd c0
> cd function0
> ls
component_state_ = 0 (SST::BaseComponent::ComponentState)
my_info_/ ()
subcompapi_counter_ = 0 (unsigned long long)
v_ping_t/ (unsigned short [1000])
v_pong_t/ (unsigned short [1000])

> cd v_ping_t
# sidebar: Preferably this would print "42" instead of the contents of v_ping_t[42].
> print 42
42 = 43 (unsigned short)

> print 43
43 = 44 (unsigned short)

> watch 42 > 43
Added watchpoint #0

> run 3ns

  Before Clock Handler
    WatchPoint c0/function0/v_ping_t/42 tests:
      c0/function0/v_ping_t/42 > c0/function0/v_ping_t/43  -> false

  ...

So we can see we are actually performing the comparison v_ping_t[42] > v_ping_t[43] which is not what we intended.

[feldergast]

For array items, I suggest we just prefix the number with something. Anything really, so that it is not just a valid number. The other option is to make the name [0], [1], [2], etc.

[kpgriesser]

@donofrio Noting that this will be fixed when object tree PR is merged.