I have added a new Intrinsic to RISCV Backend. Now I am planning to implement a Pass to insert the custom Intrinsic at the start of every function, as the first instruction, in-accordance with a command line argument which specifies the list of functions to be omitted. Is it possible to implement this as a normal FunctionPass called via opt tool? Or, should I call use the MachineFunctionPass?
Also, if I have to use the MachineFunctionPass, is it possible to automatically enable that pass from Clang command line, similar to how the normal opt based Target-Independent passes are enabled via -Xclang -load ?
Please guide me in this.
Thank you so much.
Related
I am evaluating Keil Microvision IDE on STM32H753.
I am doing compiler comparison between ARMCC5 and AC6 in the different optimisation levels. AC6 is based on Clang.
My code is not using memcpy and I have unchecked "Use MicroLIB" in the project settings , However a basic byte per byte copy loop in my code is replaced by a memcpy with AC6 (only in "high" optimisation levels). It doesn't happen with ARMCC5.
I tried using compilation options to avoid that, as described here: -ffreestanding and -disable-simplify-libcalls, at both compiler and linker levels but it didn't change (for the second option, I get an error message saying that the option is not supported).
In the ARMCLANG reference guide i've found the options -nostdlib -nostdlibinc that prevent (??) the compiler to use any function of a standard lib.
However I still need the math.h function.
Do you know how to prevent clang to use functions from the Standard C Lib that are not explicitely called in the code ?
EDIT: here is a quick and dirty reproduceable example:
https://godbolt.org/z/AX8_WV
Please do not discuss the quality of this example, I know it is dumb !!, I know about memset, etc... It is just to understand the issue
gcc know a lot about the memcpy, memset and similar functions and even they are called "the builtin functions". If you do not want those functions to be used by default just use the command line option -fno-builtin
https://godbolt.org/z/a42m4j
I use Xcode7 to debug a App.
Seems step into behave like the step over, can't jump into the execution of a sub procedure? It's just jump to the next line in the source code each time.
And if I'm debug in the UIKit method(I don't have source code), it's jump to the next instruction.
As you have found, step-in avoids frames with no debug information. Most people like to just hit one step command, rather than switching between step & next depending on the line they are on, and in my experience, tend to choose step. This is made more pleasant if the debugger doesn't stop in printf & other code you have no debug info for.
However, lldb's "step" command has an option to control this:
-a <boolean> ( --step-in-avoids-no-debug <boolean> )
A boolean value that sets whether stepping into functions will step over functions with no debug information.
If you use this frequently, you can either reset the step alias to include this option, or make another alias that includes it. Use the command alias command to do this.
And if you always want step-in to step into code with no debug information, just set the global setting:
settings set target.process.thread.step-in-avoid-nodebug 0
either at the start of a debug session or in your .lldbinit.
Note, most of lldb's commands are documented in the help system. For instance, help step would have shown the above option for the step command, and apropos step would have shown the setting.
From GDB Manual:
Also, the step command only enters a function if there is line number information for the function. Otherwise it acts like the next command. This avoids problems when using cc -gl on MIPS machines. Previously, step entered subroutines if there was any debugging information about the routine.
And I found Step into works well when I have source file.
So maybe I have make a mistake. But the lldb is very lack of documents.
I have a custom dissector (written in Lua) that I am using in many aspects of my current project.
I would also like to write a tap to perform some specific calculations for a particular task. I would like to keep this separate from the general purpose dissector for purposes of modularity.
Is there a way to invoke a dissector and a tap, both written in Lua, from the tshark command line? More generally, can an arbitrary number of Lua scripts be invoked, and if so, will they get invoked in the correct order?
EDIT:
I have tried invoking the two scripts from the command line:
tshark -Xlua_script:my_diss.lua -Xlua_script:my_tap.lua -r my.pcap
But I get an error:
tshark: Lua: Error during loading:
[string "my_tap.lua"]:9: bad argument #1 to 'new' (Field_new: a field with this name must exist)
The field name that this line refers to is created in my_diss.lua, but it is apparently not visible when my_tap.lua is being loaded.
That would require that the "initialize Lua" code in libwireshark be told which Lua scripts are dissectors and which Lua scripts are taps, and load them at the appropriate time so that, for example, all dissectors are loaded before all taps.
That means Wireshark would have to be changed; please file an bug at the Wireshark Bugzilla for this.
This is now supported in the wireshark codebase (version 1.8.5). I built from source and was able to get the desired behavior.
The relevant issue is: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6020
The relevant commit is: http://anonsvn.wireshark.org/viewvc?view=revision&revision=47877
I want to have two lexers in one project, and I don't want to run into problems with having multiple yylex functions in the build. Can I make lex output with a different prefix?
You can use the -Pprefix parameter for flex in your makefile. Using flex -Pfoo you would effectively prefix all yy generated functions. Have a look at the manual page for further details.
flex lets you do that. Just define the YY_DECL macro. Dunno about actual Unix(tm) lex(1) though.
You could build a C++ lexer. This means all the state information is held in an object.
Then it is just a matter of using the correct object!
How can I tell if a module is being called dynamically or statically?
If you are operating on z/OS, you can accomplish this, but it is non-trivial.
First, you must trace up the save area chain and use CSVQUERY to find out which program owns each save area. Every other program will be a Cobol runtime module, like IGZCPAC. Under IMS, CICS, TSO, et al, those modules might be different. That is the easy part.
Once you know who owns all the relevant save areas, you can use the OS LOADER / BINDER / LINKER utilities to discover what artifacts are in the same modules. This is the non-easy part.
The ONLY way is to look at the output of the linkage editor (IEWL) or the load module itself. If the module is being called DYNAMICALLY then it will not exist in the main module, if it is being called STATICALLY then it will be seen in the load module. Calling a working storage variable, containing a program name, does not make a DYNAMIC call. This type of calling is known as IMPLICITE calling as the name of the module is implied by the contents of the working storage variable. Calling a program name literal.
Calling a working storage variable,
containing a program name, does not
make a DYNAMIC call.
Yes it does. Call variablename is always DYNAMIC.
Call 'literal' is dynamic or static according to the DYNAM/NODYNAM compiler option.
Caveat: This applies for IBM mainframe COBOL and I believe it is also part of the standard. It may not apply to other non-standard versions of COBOL.
For Micro Focus COBOL statically linking is controlled via call-convention on the call (bit 3) or via the compiler directive LITLINK.
When linking statically the case of the program-id/entry-point and the call itself is important, so you may want to ensure it is exact and use the CASE directive.
The reverse of LITLINK directive is the NOLITLINK directive or a call-convention without bit 3 set!
On Windows you can see the exported symbols in your .dll by using the "dumpbin /exports" utility and on Unix via the 'nm' utility.
A import .lib for the .dll created via "cbllink" can be created by using the '-K'command line option on cbllink.
Look at the call statement. If the called program is described in a literal then it's a static call. It's called a dynamic call if the called program is determined at runtime:
* Static call
call "THEPROGRAM"
* Dynamic call
call wsProgramName