Looking for ideas of how to disable a uvm_warning that occurs in the `uvm_object_utils macro.
UVM_WARNING #0: reporter [TPRGED] Type name 'xxx_packet' already registered with factory. No string-based lookup support for multiple types with the same type name.
I don't care about string-based lookup and I'd like to be able to use the same class name in multiple tests (I'm using per-test packages to make this work). So I'd really like to disable this warning. However, even the command the command line disable doesn't seem to help.
I tried:
+uvm_set_action=*,TPRGED,UVM_WARNING,UVM_NO_ACTION
This works for other warnings, but in this case the warning seems to occur even before command line arguments are processed.
These messages come because of static initializations, you will not be able to turn them off.
If you don't want register string names with the factory, use the `uvm_object_param_utils macro instead of the `uvm_object_utils The only difference that is does not register a string with the factory. See http://go.mentor.com/mcem for more information.
Related
While compiling and Xcode swift project for MacOS, not used functions are removed from the binary (removed by the optimizer I guess). Is there a way to tell the compiler to not remove unused functions, perhaps with a compiler option (--force-attribute?) so that even with optimization enabled those functions remain in the binary?
I know that if a global function is declared as public (public func test()) then it's not removed even if not used (Since it can be used by other modules), but I can't use public since that would export the symbol for that function.
Any suggestion?
If this is indeed removed by the optimiser, then the answer is two-fold.
The optimiser removes only things that it can prove are safely removable. So to make it not remove something, you remove something that the optimiser uses to prove removability.
For example, you can change the visibility of a function in the .bc file by running a pass that makes the functions externally callable. When a function is private to the .bc file (also called module) and not used, then the compiler can prove that nothing will ever call it. If it's visible beyong the .bc file, then the compiler must assume that something can come along later and call it, so the function has to be left alive.
This is really the generic answer to how to prevent an optimisation: Prevent the compiler from inferring that the optimisation is safe.
Writing and invoking a suitable pass is left as an exercise for the reader. Writing should be perhaps 20 lines of code, invoking… might be simple, or not, it depends on your setting. Quite often you can add a call to opt to your build system.
As I discovered, the solution here is to use a magic compiler flag -enable-private-imports (described here: "...Allows this module's internal and private API to be accessed") which basically add the function name to the list #llvm.used that you can see in the bitcode, the purpose of the list is:
If a symbol appears in the #llvm.used list, then the compiler,
assembler, and linker are required to treat the symbol as if there is
a reference to the symbol that it cannot see (which is why they have
to be named)
(cit.) As described here.
This solves my original problem as the private function even if not used anywhere and not being public, during compilation is not stripped out by the optimiser.
I am trying to add an accelerator to the rocket chip framework through the MMIO peripheral. I went through the GCD example and was able to build the basic GCD code. I then replaced the GCD with an accelerator which has it's own Config, Parameters and Field information. Now when I try to pass this information to the rocket chip there is a name clash with the freechips.rocketchip.config.{Parameters, Field, Config}. I tried specifying the whole path i.e; accelerator.util.conig.Parameters to distinguish it from freechips.rocketchip.config.Parameters but it still gave me the same error. When I remove my accelerator configs and parameters and pass simple hand made parameters the build is successful, however, when I add my config I get %Error-TIMESCALEMOD and this error is in the generated file which I am not modifying. I tried a work around by altering my verilator options but that goes down a rabbit hole of errors. I have narrowed down the problem to the fact that this is being caused because I am using two different configs both of which have their own Config.scala file shown here Is there a way to fix this problem? I have attached the error with this question.
The problem was with a blackbox, not sure why it was giving me that error, but yes we can mix two different configs having different util.config files. We just have to specify them explicitly.
I've been trying a solution for this, but. I cannot find it.
What I'm trying to do, is work with the "bind by reference" ability, but working with ILE RPG written with embedded sql.
I can use the BNDDIR ctl opt in my source. And everything works correctly.
But that means a "bind by copy" method. Checked deleting the SRVPGM and even the BINDDIR. And the caller program still works.
So, is there any way to use "bind by reference" in an ILERPGSQL program?
After my question, an example:
Program SNILOG is a module, that conains several procedures. Part of them, exported.
In QSRVSRC I set the exported procedures, with a source with the same name: SNILOG. Something like this:
STRPGMEXP PGMLVL(*CURRENT)
/************************************************** ******************/
/* *MODULE SNILOG INIGREDI 04/10/21 15:25:30 */
/************************************************** ******************/
EXPORT SYMBOL("GETDIAG_TOSTRING")
EXPORT SYMBOL("GETDIAGNOSTICS")
EXPORT SYMBOL("GRABAR_LOG")
EXPORT SYMBOL("SNILOG")
ENDPGMEXP
As part of the procedures are programmed with embedded sql, the compilation must be done with CRTSQLRPGI, using the parameter OBJTYPE(*SRVPGM).
So, I finally get a SRVPGM called SNILOG, with those 4 procedures exported.
Once I've got the SRVPGM, I add it to a BNDDIR called SNI_BNDDIR.
Ok, let's go to the caller program: SNI600V.
Defined with
dftactgrp(*no)
, of course!.
And compiled with CRTSQLRPGI and parameter OBJTYPE(*PGM).
Here, if I use the control spec
bnddir('SNI_BNDDIR')
, it works fine.
But not fine enough, as this is a "bind by copy" method (I can delete the SRVPGM or the BNDDIR, and it is still working fine).
When I'm not working with SQL, I can use the CRTPGM command, and I can set the BNDSRVPGM parameter, to set the SRVPGM the program is going to be called. Well, just their procedures...
But I cannot find any similar option in CRTSQLRPGI command.
Nor in opt codes in ctl-opt sentence (We have BNDDIR, but not BNDSRVPGM option).
Any idea?
I'm running V7R3M0 with TR level: 6
Thanks in advance!
the use of
bnddir('SNI_BNDDIR')
Is the way to bind by reference OR bind by copy.
The key is what does your BNDDIR look like?
If you want to bind by reference, then it should include *SRVPGM objects.
If you want to bind by copy, then it should include *MODULE objects.
Generally, you want a *BNDDIR for every *SRVPGM that includes the modules (and maybe a utility *SRVPGM or two) needed for building a specific *SRVPGM.
Then one or more *BNDDIR that includes just *SRVPGM objects that are used to build the programs that use those *SRVPGMs.
This post showed me how to see stuff in SMM. And I notice that Simics shows other normally "hidden" registers like the segment descriptor shadow values, which only get updated indirectly. So is it possible to see the "smbase" register in Simics?
To read one MSR, currently you need to use interface calls on the processor. The "%" operator reads named registers on the current processor. Calling the iface inspects any processor object, and works for-only-has-a-number MSRs.
Use online help to figure out how to use the interface. For example:
simics> #conf.board.mb.cpu0.core[0][0].iface.x86_msr.get_number("IA32_TSC_DEADLINE")
1760
simics> api-help x86_msr_interface_t
Help on API keyword "x86_msr_interface_t":
DESCRIPTION
SIM_INTERFACE(x86_msr) {
void (*register_handlers)(
conf_object_t *cpu,
int64 number,
x86_msr_getter_func_t getter,
lang_void *getter_data,
x86_msr_setter_func_t setter,
lang_void *setter_data,
...
Adding a command for inspection is on the wish list.
UPDATE.
The interface also provides the ability to look up from number to name. For the case of MSR 0x9E, IA32_SMBASE, on the "client" core in Public Simics, looking up the name yields this:
simics> #conf.board.mb.cpu0.core[0][0].iface.x86_msr.get_name(158)
'msr_ia32_smbase'
simics> #conf.board.mb.cpu0.core[0]0].iface.x86_msr.get_number("msr_ia32_smbase")
158
For historical reasons, the register is called msr_ia32_smbase, and not IA32_SMBASE from the manual. In general, looking things up by number is a bit more robust. Esp since many MSRs just have numbers in the Simics model as it is currently set up.
First, you may search the loaded configuration for a particular string using the apropos command (a for short). And since smbase is likely exposed via an attribute it would look like a -a smbase. And if there are anything "smbase" in the configuration you will see it.
I loaded the QSP-x86 Firststeps platform and got several hits on the form
<cpu-class>.msr_ia32_smbase
Also, in general it helps knowing the context of a certain something. Such that smbase is "part of" MSR.
This seems like a simple thing, but I can't find an answer in the existing questions:
How do you add a global argument to all your present and existing run or debug configurations? In my case, I need a VM argument, but I see that this could be useful for runline arguments as well.
Basically, every time I create a unit test I need to create a configuration (or run, which creates one), and then manually edit each one with the same VM argument. This seems silly for such a good tool.
This is not true. You can add the VM arguments to the JRE definition. This is exactly what it is for. I use it myself so that assertions are enabled and heap is 1024mb on every run, even future ones.
Ouch: 7-years bug, asking for running configuration template, precisely for that kind or reason.
This thread proposes an interesting workaround, based on duplicating a fake configuration based on string substitution:
You can define variables in Window->Preferences->Run/Debug->String Substitution. For example you can define a projectName_log4j variable with the
correct -Dlog4j.configuration=... value.
In a run configuration you can use ${projectName_log4j} and you don't have to remember the real value.
You can define a project-specific "empty" run configuration.
Set the project and the arguments fields in this configuration but not the main class. If you have to create a new run configuration for this project select this one and use 'Duplicate' from its popup-menu to copy this configuration.
You have to simply set the main class and the program arguments.
Also you can combine both solutions: use a variable and define an "empty"
run configuration which use this variable. The great advantage in this case
is when you begin to use a different log4j config file you have to change
only the variable declaration.
Not ideal, but it may alleviate your process.