I am dipping my toes in VxWorks driver development. My problem is that in my Kernel Configuration settings, I can search for my driver-component, but it is always greyed out and will not let me include it. When I right click it and select "check" it says "Undefined reference mydriver.o"
I read through the vxBus driver developer documentation and decided that I would test out the development flow by taking an already-existing/functioning driver and simply modify the file-name/function-name/print strings. I copied and modified the existing *.c, *.h, *.cdf, *.dc, *.dr as appropriate.
I also played around with putting the driver source files in the target/3rdparty directory as done for the "wrsample" driver.
I also tried to just throw in the correct #define statement in my config.h file to try and force the driver to be instantiated, but no luck.
Can anyone provide any help? It seems like I need to pre-build the driver source to generate a *.o file, but I'm not sure how to do this. I could not find a *.o file for the existing-driver that I modified...
Figured it out on my own. I did have to create a makefile and compile the source (in advance...before utilizing the driver in vxWorks). I used the makefile that was auto generated for my WindRiver Tornado as a template to create my driver makefile. I then created a batch file that calls the vxWorks make.
The reason that there was no object file for the existing driver is because the objects get added to the driver library (*.a) and not just a *.o.
All driver files exist in the target/3rdparty directory, but I did have to copy the *.cdf, and the *.h files into other directories to get it to work. I made this a step in my batch file.
Related
According to How does AOSP 9.0 build system link the executable? and What does # mean in this clang command in AOSP build log? , when linking a module, AOSP seems to produce a .rsp file that contains all the obj files that the module need,and pass the file name as a parameter to the link command, for example:
prebuilts/clang/host/linux-x86/clang-4691093/bin/clang++ /OpenSource/Build/Android/9.0.0_r30/soong/.intermediates/bionic/libc/crtbegin_so/android_x86_64_core/crtbegin_so.o #/OpenSource/Build/Android/9.0.0_r30/soong/.intermediates/frameworks/base/libs/hwui/libhwui/android_x86_64_core_shared/libhwui.so.rsp ......
But the .rsp files seems to be removed after build.
The question is, how are these file generated and how to get these files? This may require to learn and modify the build scripts which is out of reach for me.
There maybe the answer for you, read the ninja build manual , in that manual .rsp file mentioned.
https://ninja-build.org/manual.html
the following is info that I copy out.
rspfile, rspfile_content
if present (both), Ninja will use a response file for the given command, i.e. write the selected string (rspfile_content) to the given file (rspfile) before calling the command and delete the file after successful execution of the command.
This is particularly useful on Windows OS, where the maximal length of a command line is limited and response files must be used instead.
Is there any way to integrate EDK2 based application to come into Bulls Eye Code Coverage tool? The executable will be having .efi extension, and it open's only in EFI shell. I believe, i also need to develop an driver to capture the coverage data into external disk for analysis, as the application will be valid only in the EFI Shell(BIOS).
So, does anyone have any idea, on how it can be done, for overall EFI Applications?
Thanks,
Pramod
These are the steps I took to integrate Bullseye into EDK2 (after installing Bullseye following the instruction on the website):
Use the /run/libcov-printf.c and replace the "printf" with "AsciiPrint".
Copy all the files from /run/ to your EDK $WORKSPACE
Create library .inf file and add libcov-printf.c to its [Source] section
Add library instance to your platform .dsc file (MdeModulePkg.dsc probably)
Add library reference to your application .inf file under [LibraryClass]
Add cov_dumpData() in your application source code (usually at its exit point).
compile using EDK2 build
You'll end up with an efi binary that you can run on your target and get the measurements once the application reaches its exit point.
The output data can be redirected to a file (using the > directive inside EDK2 shell) and then be processed by covpost to be merged into the cov file created in the build process.
Well I don't know how EFI works. However bullseye coverage support the customization. When I worked for the embedded system. I created open/read/write functions to write the coverage data not to the file but to the serial cable and I created the host application to interprete the data sent from serial cable and save them into cov file. I'm not sure if this works on your case well. However you can start from the following link.
http://www.bullseye.com/help/env-embedded.html
This may be somewhat trivial, but I am attempting to work on an Action Script / Flash project and need to make some changes to it and attempt to rebuild the .SWF file associated with it.
The project itself is fairly straightforward and is available on github here It is jwagener's recorder.js, which consists of several Action Script files and a single compiled .SWF file.
I am not terribly familiar with the build process for Action Scripts and I am sure that I have all of the necessary tools (Flash Builder, Adobe Flash Professional etc.) but I am not sure about how to go about it.
I've attempted to simply create a new ActionScript project and add all of the necessary ActionScript files from his repository, but upon building the .SWF it didn't function at all and lacked all of the External Interface elements that I need to use.
Any ideas, walk-throughs, or tutorials that would point me in the right direction would be extraordinarily helpful.
The project you want to compile actually includes a Make file.
MXMLC = "/Applications/Adobe Flash Builder 4.5/sdks/4.5.0/bin/mxmlc"
build:
$(MXMLC) -debug=false -static-link-runtime-shared-libraries=true -optimize=true -o recorder.swf -file-specs flash/FlashRecorder.as
clean:
rm recorder.swf
It looks setup for osx, but you get the idea.
If you only need to do minor changes and could do without an IDE that shows error/warnings/etc. you can do this:
Download the FlexSDK
Setup an environment variable so you can access the mxmlc compiler from anywhere on your system
Navigate to your project and compile from the command line
Step 1 is trivial.
Step 2 depends on your os a bit. On Windows should be something like My Computer > Properties > Advanced > Environment variables (I remember this is on XP, should still be somewhere on the Computer Properties properties on Windows 7) and add to the PATH variable the location of the FlexSDK's bin folder. On unix you should add something like this to either ~/.profile or ~/.bash_profile : export PATH=/your/path/to/FlexSDK/bin:$PATH
At this you should be able to run mxmlc -version from the command line
Step 3 means navigating to the project and running:
mxmlc -warnings=false -debug=false -static-link-runtime-shared-libraries=true -optimize=true -o recorder.swf -file-specs flash/FlashRecorder.as
So that's the command line option in a nutshell.
If you have a bit more editing to do you can use an IDE.
If you're on Windows I warmly recommend FlashDevelop: it's fast/lightweight/free/opensource. It downloads the sdk and setups everything for you.
If you're on OSX you can use FDT 5 Free or a trial version of Flash Builder(60 days by default) or setup TextMate with the actionscript 3 bundle.
When managing a grails plugin in Intellij Idea (I'm using version 10.5.2 on OSX, if it matters), I can't get it to add the *GrailsPlugin.groovy file to the classpath in a way that it can be recognized by unit tests run from the IDE. The tests run fine from the command line using grails test-app; I just want IDEA to be able to run them too.
The problem is that the *GrailsPlugin.groovy file is at the top level directory in the plugin, which is not marked as a source directory in IDEA. I definitely don't want to make it a source folder, since that will screw up lots of things such as the package path to all of my regular source files (amongst many other issues).
I've tried adding *GrailsPlugin.groovy to my Settings->Compiler Resource Patterns, but to no avail. Since the file isn't in a source folder, it's ignored.
I tried creating a source folder that has a symlink to the *GrailsPlugin.groovy file, but that introduces all kinds of synchronization issues.
Anyone have any ideas?
I have an erlang application I have been writing which uses the erldis library for communicating with redis.
Being a bit of a newbie with actually deploying erlang applications to production, I wanted to know if there was anyway to 'bundle' these external libraries with the application rather than installing into my system wide /usr/lib/erlang/lib/ folder.
Currently my directory structure looks like...
\
--\conf
--\ebin
--\src
I have a basic Makefile that I stole from a friend's project, but I am unsure how to write them properly.
I suspect this answer could involve telling me how to write my Makefile properly rather than just which directory to plonk some external library code into.
You should really try to avoid project nesting whenever possible. It can lead to all sorts of problems because of how module/application version is structured within Erlang.
In my development environment, I do a few things to simplify dependancies and multiple developed projects. Specifically, I keep most of my projects sourced in a dev directory and create symlinks into an elibs dir that is set in the ERL_LIBS environmental variables.
~/dev/ngerakines-etap
~/dev/jacobvorreuter-log_roller
~/dev/elib/etap -> ~/dev/ngerakines-etap
~/dev/elib/log_roller -> ~/dev/jacobvorreuter-log_roller
For projects that are deployed, I've either had package-rpm or package-apt make targets that create individual packages per project. Applications get boot scripts and init.d scripts for easy start/stop controls but libraries and dependancy projects just get listed as package dependencies.
I use mochiweb-inspired style. To see example of this get your copy of mochiweb:
svn checkout http://mochiweb.googlecode.com/svn/trunk/ mochiweb
and use
path/to/mochiweb/scripts/new_mochiweb.erl new_project_name
to create sample project of the structure (feel free to delete everything inside src afterwards and use it for your project).
It looks like this:
/
/ebin/
/deps/
/src/
/include/
/support/
/support/include.mk
Makefile
start.sh
ebin contains *.beam files
src contains ***.erl files and local *.hrl files
include contains global *.hrl files
deps contains symlinks to root directories of dependencies
Makefile and include.mk takes care of including appropriate paths when project is built.
start.sh takes care of including appropriate paths when project is run.
So using symlinks in deps directory you are able to fine tune the versions of libraries you use for every project. It is advised to use relative paths, so afterwards it is enough to rsync this structure to the production server and run it.
On more global scale I use the following structure:
~/code/erlang/libs/*/
~/code/category/project/*/
~/code/category/project/*/deps/*/
Where every symlink in deps points to the library in ~/code/erlang/libs/ or to another project in the same category.
The simplest way to do this would be to just create a folder named erldir and put the beams you need into it and then in your start script just use the -pa flag to the erlang runtime to point out where it should fetch the beams.
The correct way (at least if you buy into the OTP distribution model) would be to create a release using reltool (http://www.erlang.org/doc/man/reltool.html) or systools (http://www.erlang.org/doc/man/systools.html) which includes both your application and erldis.
Add the external libraries that you need, anywhere you want them, and add them to your ERL_LIBS environment variable. Separate the paths with colon in unix or semicolon in dos.
Erlang will add the "ebin"-named subdirs to its code loading path.
Have your *.app file point out the other applications it depends on.
This is a good halfway-there approach for setting up larger applications.
Another way is put your lib path in ~/.erlang.
code:add_pathz("/Users/brucexin/sources/mochiweb/ebin").
code:add_pathz("/Users/brucexin/sources/webnesia/ebin").
code:add_pathz("./ebin").
code:add_pathz("/Users/brucexin/sources/erlang-history/ebin/2.15.2").