When using the Windows software trace preprocessor (WPP) component of Event Tracing for Windows (ETW), you must include a file that contains 3 macros:
WPP_INIT_TRACING macro activates software tracing
DoTraceMessage macro to log trace messages
WPP_CLEANUP macro deactivates software tracing
The include file containing these macros are generated automatically when you add the following to the bottom of a source file:
RUN_WPP= $(SOURCES)
Since these things are macros, they actually expand to do something else. i need an example of what these macro's expand to.
The reason i need a sample of these generated macros is that i do not own Visual Studio, nor am i writing in C/C++, or using a Microsoft compiler.
Bonus Chatter. The Microsoft SDK provides a sample include file (tracedrv.tmh) that contains the macro definitions.
To use WPP, Windows Driver Kit must be installed. Just download WDK and install it.
After installation, there is a buidable WPP sample driver at:
C:\WinDDK\7600.16385.1\src\general\tracing\tracedrv
Those macros you are looking for can be found at:
C:\WinDDK\7600.16385.1\bin\WppConfig\Rev1\km-init.tpl
C:\WinDDK\7600.16385.1\bin\WppConfig\Rev1\um-init.tpl ... etc.
The definition of those macros is available in the .TMH file created by the WPP preprocessor for your file during compilation.
The ''RUN_WPP= $(SOURCES)'' line cause execution of the WPP preprocessor TraceWpp.exe executable which is included in the DDK. The TMH files are created in the obj directory.
Related
I have C/C++ application and I am trying to run cov-build and getting a warning “ NO FILES EMITTED”. Can you please help me as we doing the POC on Coverity for static code analysis.
C:\Users\Master\bamboo-agent-home\xml-data\build-dir\DEC-L11PROJ-JOB1>cov-build --dir cov-int IarBuild.exe MainApplication\EWARM\L11_P4_uC1.ewp -build *
Coverity Build Capture (64-bit) version 2019.03 on Windows 10 Enterprise, 64-bit (build 18362)
Internal version numbers: 2c0f9c8cf4 p-pacific1-push-35439.872
IAR Command Line Build Utility V8.4.8.6680
Copyright 2002-2020 IAR Systems AB.
Total number of errors: 0
Total number of warnings: 0
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
For more details, please look at:
C:/Users/Master/bamboo-agent-home/xml-data/build-dir/DEC-L11PROJ-JOB1/cov-int/build-log.txt
First, if you are involved in a pre-sales Proof of Concept (POC), then there should be a Coverity Sales Engineer assigned to help with the POC. That person's role includes providing instructions and information similar to what I'll offer below, as well as answering technical questions such as yours. There may have been a miscommunication somewhere. Get in contact with the Sales Engineer, as they will be able to help more reliably and completely than I can.
Now, what's going on? The primary purpose of cov-build is to watch the build process for invocations of compilers, and when one is found, compile the same code using the Coverity compiler (called cov-emit). But in order to recognize a compiler, cov-build needs to know its command line name, what kind of compiler it is, where its include files are stored, etc. This is accomplished by a helper tool called cov-configure that must be run before cov-build. If cov-configure has not been run, then no compiler invocations will be recognized, which appears to be the case for you, as indicated by "No files were emitted".
Synopsys has a page called CLI Integration Cheat sheet that gives these commands for use with IAR:
cov-configure --comptype iar:arm --compiler iccarm --template
cov-build --dir <intermediate directory> "c:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\common\bin\IarBuild.exe" sample_project.ewp -build Debug -log all
I can't personally vouch for these commands (I don't have IAR, nor access to the Coverity tools anymore; I'm a former employee), but something like that will be needed. Again, your assigned Sales Engineer should be able to help.
Finally, for new Coverity users, I recommend using the cov-wizard tool. cov-wizard is a graphical front-end to the command line tools, and has help text explaining the concepts and procedures, along with a convenient interface for performing them. There are several steps even after cov-build, and cov-wizard will walk you through all of them. Its final screen shows exactly what command lines it used in case you want to script them.
I've recently switched to using PlatformIO for developing for STM32 using the following workflow:
Create a .ioc file using the CubeMX utility
Generate source code and the PlatformIO configuration from that .ioc file from the stm32pio command line utility
Edit, build, and debug using the PlatformIO plug-in for VSCode (Mac)
Overall, this works very well. However, I was previously using the CubeMX code generation in ST's CubeMX IDE, which placed a .s file in the source directory that (as I understand it) defined the NVIC, as well as the default function that was used for exceptions/interrupts that are not explicitly defined (i.e., those handled by their default weak implementations.) I don't see where this is defined in the new workflow. Is this generated dynamically as part of the build process?
The reason I'm asking is (beside wanting a better understanding of the process overall), I'd like to write an interrupt handler for EXTI0, but trigger it as a software interrupt, and not assign a pin to it. If that is not possible, then perhaps the entire point is moot.
I was able to find the answer. These steps might be useful to somebody else who comes across this question. This was done on MacOS, but should be similar to the process for other operating systems.
During the build process, the filename can be seen. It will be prefaced with startup_, followed by the name of the particular chip you're developing for. In my case, the line is
Compiling .pio/build/disco_f072rb/FrameworkCMSISDevice/gcc/startup_stm32f072xb.o
Searching in the .platformio folder of my user directory, I found the matching .s file, which in my case was .platformio/packages/framework-stm32cube/f0/Drivers/CMSIS/Device/ST/STM32F0xx/Source/Templates/gcc/startup_stm32f072xb.s
The structure of the path leading to the file indicates the particulars of the hardware and frameworks I'm using: STM32Cube framework, a F0 series chip, and the GCC compiler. The easiest way to find this file, and how I was able to find it, is using the find command from the terminal to search the PlatformIO directory.
Reading this file gives the lines I was looking for, defining the names of the functions to be used for exception and interrupt handling, such as the following:
.weak EXTI0_1_IRQHandler
.thumb_set EXTI0_1_IRQHandler,Default_Handler
It seems like, while I am using the CubeMX HAL for some drivers, the basic startup code is done using CMSIS, so it should be the same for HAL, LL, or CMSIS based builds.
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I have already set up build and debug environment for Object Pascal inside Visual Studio Code via FPC and GDB, but I just made build process work for programs containing only 1 .pas file via
"command": "fpc",
"args": [ "-g", "-Px86_64", "helloWorld.pas" ],
Now, I need to build quite big Delphi project group (something like solution?) and it contains main project file .groupproj.
Is there a way to build the .groupproj via FPC somehow?
Or at least some workaround like conversion to .lpi and then build via FPC?
Or at least call Delphi compiler/builder from VS Code and build the whole project group via it? (but I don't like this option, because I prefer to not use Delphi)
To get some facts straight for other people that might stumble on this:
FPC supports Delphi source files (.lpr/.dpr, .pp/.pas and .inc). Not Delphi meta information (.dproj/.dof/.bpg/.cfg/.groupproj) which is Delphi version dependent anyway.
Lazarus conversion tool also converts .dfms. Basically it is a .dfm cleaner and Uses clause enhancer, just like some conversion tools between Delphi versions. It by default however also does substitutions that change Delphi code (that works in FPC's Delphi (-Sd) mode) into the objfpc dialect (-S2 mode) preferred by Lazarus . Always make a backup before trying, and check the configuration of the conversion tool thoroughly.
FPC and Delphi commandline parameters are different.
FPC does not support Lazarus metadata formats like .lpi. The Lazarus utility Lazbuild however does support building Lazarus projects from the commandline.
But luckily the basics are the same
a main program or library file files)
a set of unit (.pas files) and include directories (.inc files). FPC differentiates between the two, delphi doesn't.
autocreated forms must be added to the project.
any additional commandline switches like defines to set, range checking optimization options.
So in worst case, examine the Delphi projects (either in IDE or texteditor) for directories and switches and create either a manual buildscript or a lazarus (.lpi) project.
However it is vital to keep in mind that the default FPC mode is NOT Delphi mode, so always when executing FPC make sure you manually enable Delphi mode (-Sd)
Group project support within Lazarus is very new (as in months), and afaik not even in stable versions yet. Though if you create a bunch of .lpis, a batch file/shellscript with a sequence of lazbuild commands on .lpis might do it.
P.s. throw the VSCode under the bus and use Lazarus.
so what I'm trying to do is utilize a simple Qt application IN eclipse without using the eclipse QT plugin by linking the required libraries through the GCC C++ Linker. However, I have been unable to locate the exact name of the library to use, or which libraries will be necessary. I've located the path of the Qt library my application seems to be accessing, but I continue to get an error when building that just says "-lqt" doesn't exist/can't find, etc.
The reason I'm doing this is because I'm building a simple game in OGRE for a project at the uni and wanted to use a Qt application for the GUI. Well, I didn't necessarily want too, but our professor wishes us to do so. Please don't suggest that I simply embed an Ogre widgit into my Qt application as this isn't an opti
Any ideas?
Thanks <3
Well, if you are using CMake then it should take care of everything provided that you instructed it to do so. phb provided a link to even better instructions.
First step is to instruct the CMake that we need Qt for our project. This is done with (you can specify individual parts that are needed as well):
find_package(Qt4 REQUIRED)
If Qt is not found in the typical locations (e.g. QTDIR is not set) - cmake will fail.
You also have to instruct CMake to use Qt include paths and set certain compiler definitions:
include(${QT_USE_FILE})
add_definitions(${QT_DEFINITIONS})
Finally, for each target you need to tell that you'd like to link with Qt libraries:
target_link_libraries(foo ${QT_LIBRARIES})
You might also want to process your headers and will have to process the user interface files with moc. For the details please refer to the provided links.
In addition to provided links you can have a look at the comments at the top of FindQt4.cmake file.