I tried to iterate over a basic blocks in a specific routine, but i found some problems:
VOID Routine(RTN rtn, VOID *v)
{
RTN_Open(rtn)
for (BBL bbl = RTN_BblHead(rtn); BBL_Valid(bbl); bbl = BBL_Next(bbl))
{ /* some code */ }
RTN_Close(rtn);
}
error: deprecated-declarations,
How can i fix that error, or do it by another way ?
You have a deprecated-declarations warning because RTN_BblHead is now deprecated. Use RTN_InsHead instead.
From include\pin\gen\image.ph:
/* DO NOT EDIT */
/* RTN_BblHead is now deprecated. See RTN_InsHead.
*/
extern PIN_DEPRECATED_API BBL RTN_BblHead(RTN x);
This is also mentioned in the documentation: RTN_BblHead
You can also pass -Wno-deprecated-declarations to GCC to suppress this warning.
Edit
Remember that PIN is above all a DBI (dynamic binary instrumentation) framework: it is extremely good when it comes to instrument the executed code flow, and less good when it needs to break down non executed code.
Routine instrumentation lets the Pintool inspect and instrument an entire routine when the image it is contained in is first loaded' but as the documentation points:
A Pintool can walk the instructions of a routine. There is not enough
information available to break the instructions into BBLs.
Pin find the instructions of a RTN through static discovery, so Pin cannot guarantee that it will find all the instructions in the RTN and this is even more difficult for BBLs. My guess is that they tried at some point (hence the availability of RTN_BblHead in the past) to provide static discovery of BBLs but the discovery rate was too low (or too error prone) to be deemed acceptable, so the function became deprecated.
In short, yes you need to discover a RTN instructions by instructions (knowing that pin might miss some instructions as this is done statically). You can only discover the BBLs of a routine if the routine is executed at some point.
Related
I need to use MPI spawn on a cluster. For that I understood I need to use MPI_Info_set to specify with nodes will run the spawned processes. I have tried MPI_Info_set(info, "add-host","node1,node2") but it does not work.
Below, I provide a small example of the spawning code:
MPI_Info info;
MPI_Info_create(&info);
MPI_Info_set(info,"add-host","node1,node2");
MPI_Comm_spawn("./mpiworker", MPI_ARGV_NULL,
dynamic_procs,
info, 0, MPI_COMM_WORLD,
&intercomm,
MPI_ERRCODES_IGNORE);
Is there anything else I can use?
Parameter add-host comes probably from OpenMPI (man page) and it is not supported in MPICH.
For MPICH try one of those:
host - works for me,
hosts - should work, however, it seems that it is broken in version I currently use and MPI spawns all processes at the first node passed as a parameter value; if it also happens in your case, I suggest manual assignment of hosts for each process using MPI_Comm_spawn_multiple.
Also, I have no idea how to find a list of all supported parameters - I think MPICH guys do not pay much attention to keep documentation complete.
This worked out for me, instead of just MPI_Comm_spawn. The following code will spawn 1 process per node. I could spawn more processes per node by extending the dimension of the inputs below.
MPI_Info info[2];
MPI_Info_create(&info[0]);
MPI_Info_set(info[0],"host","node1");
MPI_Info_create(&info[1]);
MPI_Info_set(info[1],"host","node2");
char *cmds[2] = { "./mpiworker", "./mpiworker" };
int np[2] = { 1, 1 };
int errcodes[2];
MPI_Comm_spawn_multiple( 2, cmds, MPI_ARGVS_NULL, np, info, 0, MPI_COMM_WORLD, &intercomm, errcodes );
//Below parallel code follows
...
The above was tested on Ubuntu-bionic with MPICH Version:3.3a2.
My example is based on the following page. If I find a more elegant way, I will repost.
So, if I want to write an Xll and license the code then I need a point at which to check the license file and if license is invalid then I want the Xll to stop working.
I see xlAutoOpen looks like a good place to inspect the license file. I also see that xlAutoOpen must return 1 according to the documentation, what happens if something other than 1 is returned? Can I abort the Xll opening? Can I force an unload?
Are there any better places to check the license and refuse to operate. Surely, I don't have to wait until the first worksheet function invocation.
I am unfamiliar with this framework currently so forgive newbie-ness.
EDIT: I suppose I can refuse to call xlfRegister. That will prevent operation.
EDIT2: From the Excel SDK Help file
xlAutoAdd ... can be used to ... check licensing information, for example.
Also, found that on MSDN xlAutoAdd
You should check licensing information in xlAutoOpen since this function is the first entry point to activate the XLL and is always called by Excel. If password is invalid just returns 0 to indicates failure to excel and do not register your UDFs (quit before to call xlfRegister).
I have noticed that if you register your UDFs and that you returns 0 ,
the xll is still loaded and UDFs are available, so the return
variable from xlAutoOpen does not seem to be taken into account by
Excel but by convention I believe it is better to keep returning zero
to indicate failure.
I believe MSDN doc is misleading.
xlAutoAdd is not suitable to check license since it is an optional function that is called only when the XLL is added by the Add-In Manager or when it is opened as a document (using File/Open). I assume that you may have trial licence and so that you should check it at every load time if the user's licence is still valid.
Example
Usually, you call xlAutoOpen from xlAutoAdd so your check will still be done :
pseudo code :
int __stdcall xlAutoAdd(void)
{
if(!Isinitialised)
if( xlAutoOpen() == 0) // licence check is still performed
returns 0 ;
...
MessageBoxA(GetActiveWindow(), "Thank you to install ...", "AutoOpen", MB_OK);
Isinitialised = true;
}
since xlAutoOpen is always called by Excel you should perform a similar check inside it :
bool Isinitialised = false;
int __stdcall xlAutoOpen(void) // Register the functions
{
if(Isinitialised)
return 1;
if(!ValidLicense()) // check licence in xlAutoOpen
return 0;
// continue initialization , registration ..
.....
Isinitialised = true;
}
Finally note that you can omit xlAutoAdd because it has no adverse consequences and is not required by Excel. Personally I do not use this function.
I'm using a Cortex-M3 LPC1548 from NXP with uVision IDE.
In the main() function, if I use:
SysTick_Config(SystemCoreClock * SYSTICK_INT_FREQ);
NVIC_EnableIRQ(SysTick_IRQn); // <--- HardFault happens in this line.
I got a HardFault exception everytime.
However, if I remove the NVIC_EnableIRQ(...) like this:
SysTick_Config(SystemCoreClock * SYSTICK_INT_FREQ);
code runs fine.
Does anyone knows why enabling Systick interrupt causes a HardFault?
I've done this before in a Cortex-M0 and never had problems.
Systick_IRQn is a negative value, you cannot use NVIC_EnableIRQ() with Systick. The out-of-bounds register access probably causes your hardfault.
The systick interrupt is enabled as soon as the corresponding bit in Systick->CTRL is set.
However, NVIC_SetPriority() supports Systick_IRQn among others like PendSV_IRQn.
What needs to be very clear here is that NVIC_EnableIRQ() can only be used to enable/disable exceptions numbers with values greater than 16.
Exceptions with numbers greater than 16 are called interrupt inputs while below 16 are system exceptions.
That means that the system exceptions listed below (example for Cortex-M3) cannot be used with NVIC_EnableIRQn():
1 Reset
2.NMU
3.HardFault
4.MemManage Fault
5.Bus Fault
6.Usage Fault
7-10. Reserved
11 SVC
12 Debug Monitor
13 Reserved
14 PendSV
15 Systick
So, the Systick Interrupt should never be activated using NVIC_EnableIRQ because it's an system exception. If one is using the CMSIS function SysTick_Config() no interrupt activation is needed since this function takes care of activating the Systick interrupt.
P.S. Information was taken from the excelent book from Joseph Yiu, The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors and by analysing the function NVIC_EnableIRQ().
I have a GSM modem and a PLC. The PLC sees a modem (I use a *.lib and functional block "openPort"), but I don't understand how send an "AT command" to the modem, for example, "ate0".
First, to increase your understanding of AT commands in general, read the V.250 specification. That will go a long way in making you an AT command expert.
Then for the actual implementation, I do not know Codesys, so the following is pseudo code of the structure you should have for handling AT commands:
the_modem = openPort();
...
// Start sending ATE0
writePort(the_modem, "ATE0\r");
do {
line = readLinePort(the_modem);
} while (! is_final_result_code(line))
// Sending of ATE0 command finished (successfully or not)
...
closePort(the_modem);
Whatever you do, never, never use delay, sleep or similar as a substitute for waiting for the final result code. You can look at the code for atinout for an example for the is_final_result_code function (you can also compare to isFinalResponseError and isFinalResponseSuccess in ST-Ericsson's U300 RIL, although note that CONNECT is not a final result code. It is an intermediate result code, so the name isFinalResponseSuccess is not 100% correct).
Hey, I am making some stuff in Objective-C++... And I must say that I am a total newbie when it comes to the Objective-C part... I don't really want to learn it, I kinda just need it for accessing a few Mac APIs (ObjC is such a dumb language).
So - compiling with g++ -x objective-c++ - and I somehow keep getting this warning:
XXX may not respond to YYY
First it was with a NSScreen, now it is with a NSWindow:
NSWindow may not respond to +initWithContentRect:styleMask:backing:defer:
I saw somewhere that I should cast it to id, but didn't work, throwing absolutely cryptic errors...
So - WHAT does this warning actually mean and HOW am I supposed to make it stop?
EDIT: Okay, apparently I need to ALLOCATE an instance first, then I can call its init function... Anyways, now the GCC is reporting:
confused by earlier errors, bailing out
And NOTHING else. This is the ONLY error that it reports. I figured that there is some error in my code that doesn't get reported... So I will post the whole file where the problem is here:
ONXeWindow::ONXeWindow(int px, int py, int sw, int sh, bool resizable){
NSRect wr = NSMakeRect(px, py, sw, sh);
int wf = 1; // titled
wf += 2; // closable
wf += 4; // miniaturizable
wf += (resizable ? 8 : 0); // resizable
wf += (false ? 128 : 0); // metal bg
useWindow = [[NSWindow alloc] initWithContentRect:wr styleMask:wf backing:2 defer:YES];
}
Also, YES, framework AppKit was imported (in the header file) - I am not going to confuse you with my weird file scheme here.
The message isn't really cryptic, you just don't know the language (and don't care to, by your own admission).
Since Objective-C methods are dispatched dynamically at run-time, you can call a method that the compiler doesn't have any knowledge of, however, the compiler is warning you that you're doing so. The + in the beginning of the method name means that you're calling a class method (a - would indicate that you're calling a method on an instance). Since NSWindow has no class method named initWithContentRect:styleMask:backing:defer:, the compiler is giving you a warning, and in this case, it's a pretty good one.
You probably wrote something like:
NSWindow* myWindow = [NSWindow initWithContentRect:rect styleMask:0 backing:0 defer:NO];
when you meant to write something like:
NSWindow* myWindow = [[NSWindow alloc] initWithContentRect:rect styleMask:0 backing:0 defer:NO];
The first one sends the message directly to the class, but this is an instance method. You need to allocate an instance of NSWindow first, then send the init message. Also, clang tends to give much better warning and error messages than gcc. Clang 2.0 also handles C++ and ObjC++ pretty well, so it might be worth it to switch to clang.
Checkout this example, looks like you are not allocating your objects.