SC_REPORT_* Confusion

[bfarkas]

I am a bit confused about the correct usage of the SC_REPORT_* macros.
 
In "sysc/kernel/sc_simcontext.cpp" we have:

SC_REPORT_INFO("/OSCI/SystemC","Simulation stopped by user.");

The above is helpful as it produces easily parseable output.
 
Whereas in "sysc/kernel/sc_object_manager.cpp" we have:

std::string message = result_orig_string; 
message += ". Latter declaration will be renamed to ";
message += result_string;
SC_REPORT_WARNING( SC_ID_INSTANCE_EXISTS_, message.c_str());

This is not so helpful, since it is not clear where the error comes from when analysing output.
 
A quick grep showed that there are a lot of instances where the first argument to a SC_REPORT_* macro is some ID and not the source of the error. Those IDs are resolved to error message strings, which in my opinion should go into the second argument.
 
Could someone please clarify which way is correct?

 

I would like to be able to handle the sc_report messages with our own message handler.

 

[Philipp A Hartmann]

There is a recommendation in IEEE 1666-2011 (8.3.1) on the format of the message type:
 

 

In order to define application-specific actions to be taken when a report is generated, reports are categorized according to their severity level and message type. Care should be taken when choosing the message types
passed to function report in order to give the end user adequate control over the definition of actions. It is recommended that each message type take the following general form:

   "/originating_company_or_institution/product_identifier/subcategory/subcategory..."

It is the responsibility of any party who distributes precompiled SystemC code to ensure that any reports that the end user may need to distinguish for the purpose of setting actions are allocated unique message types.

 

The message types used in the SystemC proof-of-concept implementation currently do not follow this scheme in many cases, as the reporting mechanism predates the definition of the IEEE standard for SystemC.  In order to maintain backwards-compatibility, the existing message type strings have not been adapted.

 

There needs to be a distinction between different message types in order to allow custom actions, severities etc. for individual message categories.  In order to adapt the SystemC kernel to the above scheme, we would essentially need the same "IDs" as we have right now, and would just add some "/../..." prefix to them.  But this would require changes to all existing models working with the existing IDs today.

 

Hope that helps,

  Philipp