I know when creating shader module in Vulkan you can specify the entry point in VkPipelineShaderStageCreateInfo using pName.
However, I haven't been able to use another entry point but 'main' in my glsl/spv file.
typedef struct VkPipelineShaderStageCreateInfo {
VkStructureType sType;
const void* pNext;
VkPipelineShaderStageCreateFlags flags;
VkShaderStageFlagBits stage;
VkShaderModule module;
const char* pName;
const VkSpecializationInfo* pSpecializationInfo;
} VkPipelineShaderStageCreateInfo;
Has anyone ever use this feature and can give me an example? Thank you
I was trying it some way back and I believe this is not currently possible using the official glslc or glslangValidator.
Note GLSL mandates a main function, so the autors probably found it unuseful.
glslc outright says that relevant parameter works only for HLSL.
glslangValidator is less clear, but relevant parameters are (in the time of writing) ignored when GLSL is used.
UPDATE:
There is a relevant GitHub Issue. And this feature got supported. So you have to either wait for next SDK release, or build the compiler from master.
Indeed testing that version it works with:
glslangValidator.exe -V -H -e mymain --source-entrypoint main -o hello.spv hello.vert
The compiler logs an error if non-main function is used in GLSL, but it seems to work anyway:
glslangValidator.exe -V -H -e mymain --source-entrypoint sourcemain -o hello.spv hello.vert
Related
I'm very new to this OpenSSL stuff and trying to learn my way through it. I want to generate an ec key but its keep failing to generate. I'm currently using OpenSSL 1.1.1n and here's a snippet based on understaning of EC_Key through documentation and from other people's example online:
EC_KEY* key = EC_KEY_new_by_curve_name(NID_secp521r1);
if (!key)
{
ERROR
}
EC_GROUP* ecgroup = EC_GROUP_new_by_curve_name(NID_secp521r1);
if (ecgroup)
{
printf("ECGROUP IS NOT NULL!\n");
if (EC_KEY_set_group(key, ecgroup) != 1)
{
ERROR
}
}
if (EC_KEY_generate_key(key) != 1) //<-- fails at this function
{
ERROR
}
Maybe this piece of code is from an older version of OpenSSL but I don't see that function being mentioned in a change log. Any help would be really appreciated! Thanks in advance!
Edit:
Thanks for Jakob's answer I was able to get some more information about the failure by using ERR_get_error() function. The error I see now is
error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy
The manual states:
EC_KEY_generate_key() generates a new public and private key for the
supplied eckey object. eckey must have an EC_GROUP object associated
with it before calling this function. [...]
Did you associate an EC_GROUP with the key before calling the function? There is a function called EC_KEY_set_group() which can be used to add a group object. Such an object can be created with the EC_GROUP_new().
By the way is there a reason, why you are still using OpenSSL 1.1.1. I would recommend using the latest version of the library OpenSSL 3.0. Even if you only want to learn stuff, it is probably more useful, if you immediately learn the newer version.
Edit
I do not know, what is behind your ERROR macro, but it might be a good idea to learn the OpenSSL error handling system. There are functions like ERR_print_errors() that maybe could have given you a hint about what was going wrong.
Answering myself in case someone is having this same issue.
I was able to get around this problem by building OpenSSl with no-shared flag. I'm not sure how that is affecting the lib in getting an entropy but that's the parameter that made the EC_KEY_generate_key() work.
Here's my working configuration command:
perl Configure no-shared VC-WIN32
My Usecase:
I have two c language files: ApplicationCode.c and UserCode.c . Application code is something generated by my app and UserCode is available to my application user where he can write his own code.
ApplicationCode.c internally uses UserCode.c and calls out its methods/function.
One thing you can assume here that ApplicationCode.c will never have any errors but could have warnings generated by gcc compiler. And UserCode.c can have both errors and warnings.
So, While compiling code I wanted to show user his code's errors as first priority. If needed to show warning also then show warning generated by his code only not from ApplicationCode.c (As i don't want to expose my ApplicationCode.c's code).
One more constraint is here that I wanted to show return-type warning as error here and for this I am using -Werror=return-type argument.
So, I am thinking of following three approaches to do this:
If I could able to disable all the warnings and enable only -Wreturn-type
Raised a saparate question for this here
If I could able to instruct gcc (or redirect) only error messages to stderr and rest on stdout.
Raised a saparate question for this also here
If I could able to disable all the warnings (which are enabled by default) from ApplicationCode.c file and enable all with -Werror=return-type for UserCode.c
I tried searching everywhere but did not get any solution for all the above 3. Let me know how could I achieve above problems or if there any other better way to do solve my use case ?
Update 1:
Here is my both the code file look like
ApplicationCode.c
#include <stdio.h>
// some headers
// some application specific code
int testUserFunction(); // user function declaration
int main(int argc, char *a[]) {
int result = testUserFunction(); // calling user function
// some logic to use and evaluate result
}
UserCode.c
#include<stdio.h>
int testUserFunction(int input1)
{
// user will write his code below this
// user code
}
Base command to compile code:
gcc -o code.out ApplicationCode.c UserCode.c
or if there any other better way to do solve my use case ?
If you don't want to "expose ApplicationCode.c", then why are you showing its compilation output in the first place? Solution: Compile it in somewhere secret and let the user link their UserCode.c with it.
I'm new to LLVM. I am using the clang c++ API to compile multiple stub files (in c) to IR, and then stick them together using IR builder (after linking them) to eventually run via JIT.
All this works great, unless I add a functionInlining pass to my optimizations, at which point one of these function calls made in IR builder will trigger the following exception when the pass manager is run:
Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/mike/Development/llvm/llvm/lib/IR/Value.cpp, line 356.
This is how I make the call instruction (pretty straight forward):
Function *kernelFunc = mModule->getFunction( (kernel->Name() + StringRef("_") + StringRef(funcName)).str());
if (kernelFunc){
CallInst* newInst = builder.CreateCall(kernelFunc, args);
}
Later the module is optimized:
legacy::PassManager passMan;
PassManagerBuilder Builder;
Builder.OptLevel = 3;
//Builder.Inliner = llvm::createFunctionInliningPass(); //commenting this back in trigger the exception
Builder.populateModulePassManager(passMan);
passMan.run( *mModule ); //exception occurs before this call returns
Any ideas what to look for?
Try running llvm::verifyModule on your module to see if it's correct. You might have an error and have been getting lucky beforehand but it tripped something up in the inliner.
In general assertions check a subset of things that can be wrong with your module but verify checks a lot more.
It could be a bug in LLVM but more than likely it's a bad module, it's easy to happen.
So I finally setup my dev environment so I could inspect the assertion call in the debugger. I turns out the basic block being replaced had a different context set than the one it was being replaced with. going back and making sure IRBuilder was using the same context as the IR parsers solved the problem.
So...I have a kernel mode component and a user mode component I'm putting together using the turnkey build environment of the NT DDK 7.1.0. The kernel component is all .c/.h/.rc files. The user mode component is .cpp/.c/.h/.rc files.
At first it seemed simplest to use build for both, as I saw you could modify the ./sources file of the user mode component to say something like:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
UMTYPE = windows
UMENTRY = winmain
USE_MSVCRT = 1
That didn't seem to cause a problem and so I was pleased, until I tried to #include <string> (or <memory>, or whatever) Doesn't find that stuff:
error C1083: Cannot open include file: 'string': No such file or directory
Still, it's compiling the user mode piece with C++ language semantics. But how do I get the standard includes to work?
I don't technically need to use the DDK build tool for the user mode piece. I could make a visual studio solution. I'm a bit wary as I have bumped into other annoyances, like the fact that the DDK uses __stdcall instead of __cdecl by default... and there isn't any pragma or compiler switch to override this. You literally have to go into each declaration you care about and change it, assuming you have source to do so. :-/
I'm starting to wonder if this is just a fractal descent into "just because you CAN doesn't mean you SHOULD build user mode apps with the DDK. Here be dragons." So my question isn't just about this particular technical hurdle, but rather if I should abandon the idea of building a C++ user mode component with the DDK tools...just because the kernel component is pure C.
To build a user mode program with WINDDK you need to add some variables to your SOURCES file:
386_STDCALL=0 to use cdecl calling convention by default
USE_STL=1 to use STL
USE_NATIVE_EH=1 to add a support for exception handling
Everything else you already have.
I'll put my full SOURCES file for reference:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
TARGETPATH = obj
UMTYPE = console
UMENTRY = main
USE_MSVCRT = 1
USE_NATIVE_EH=1
USE_STL=1
386_STDCALL=0
SOURCES= main.cpp
And main.cpp:
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s = "bla bla bla!";
cout << s;
return 0;
}
Have fun!
Quick Answer
Abandon the idea of building user-mode components with DDK tools (although I find the concept fascinating :-P)
Your kernel mode component should be built separately from the user mode components as a matter of good practice.
Vague thoughts
Off the top of my head, and this really speaking from limited experience...there are a lot of subtle differences that can creep up if you try to mix the two together.
Using your own example of __cdecl vs __stdcall; You have two different calling conventions. _cdecl is all kernel stuff and all of the C++ methods are wrapped around in WINAPI (_stdcall) passing conventions and __stdcall will clean do auto stack clean up and expect frame pointers inserted all over the place. And if you by accident use compiler options to trigger a __fastcall, it would be a pain to debug.
You can definitely hack something together, but do you really want to keep track of that in your user-space code and build environment? UGH I say.
Unless you have very specific engineering reasons to mix the two environments, (and no a unified build experience is not a valid reason, because you can get that from a batch file called buildall.bat) I say use the separate toolchains.
I'm having a problem with eclipse C++. My project compiles and runs but eclipse (juno) keeps saying there are thousands of errors. For example there's a function SetRun in my code, and eclipse mentions this error: "called Invalid arguments 'Candidates are: void SetRun(?)'", whereas SetRun is of type static void SetRun (uint32_t run);
I have quite a lot of similar errors like that, where eclipse doesn't seem to understand the type of the function and puts a '?' instead.
I also have many errors like this: "symbol '*' could not be resolved."
I think this is all part of the same issue.
What can I do to make eclipse stop telling me about these errors?
I tried the proposed solution and it did not work for me. What helped was to turn off CodeAnalysis for the project. I went to Properties->C/C++ General->Code analysis. Selected Use Project Settings and turned off all errors. This is of course very annoying and unfortunate and I would be glad to know when it is properly fixed. It is a shame we can't get use of the feature any other decent IDE has.
Actually Eclipse is some kind of unstable project. Try to clean and refresh the project.
In Eclipse:
right click the project,
click properties
Expand "C/C++ general" the item in the left hand tree view by clicking the arror, (just clicking the item itself does not expand the suboptions)
From the suboptions select "Preprocessor Include Paths, Macros etc."
Click the tab "Providers" and check the box next to "CDT GCC Built-in Compiler Settings [ Shared ]".
I had a lot of these errors whicle to trying to get CODAN to run over some code which was destined for a Mac. My Mac SDK libraries were included via symlinks as in this question (but not all of them - stay tuned!) In the end, it turned out that I didn't have all the headers included. For example, I had the following function call:
IORegistryEntryGetParentEntry(service, kIOServicePlane, &parent);
Which was giving the error:
Invalid arguments 'Candidates are: ? IORegistryEntryGetParentEntry(?,?,?)'
Now, the correct signature of the function, defined in IOKit/IOKitLib.h (which I did have) is:
kern_return_t IORegistryEntryGetParentEntry(
io_registry_entry_t entry,
const io_name_t plane,
io_registry_entry_t *parent );
Now, if we take the first argument and trace the type definitions, we get:
typedef io_object_t io_registry_entry_t; (in IOKit/IOTypes.h)
typedef mach_port_t io_object_t; (in IOKit/IOTypes.h)
typedef mach_port_name_t mach_port_t; (in mach/port.h)
typedef natural_t mach_port_name_t; (in mach/port.h)
And then! I didn't have the include which defined __darwin_natural_t. This include was actually in i386, which I didn't have in my symlink directory. Adding it completed the chain:
typedef __darwin_natural_t natural_t; (in i386/vm_types.h)
typedef unsigned int __darwin_natural_t; (in i386/_types.h)
Finally, CODAN knew what type argument 1 of IORegistryEntryGetParentEntry() was supposed to be, and the error changed to:
Invalid arguments 'Candidates are: kern_return_t IORegistryEntryGetParentEntry(io_registry_entry_t ,?,io_registry_entry_t*)'
I repeated this "type-trace" for the other arguments, and found that the error disappeared (I didn't even need to rebuild the index, but YMMV). Of course, you would need to find the headers that you need and may sure they are included - the above is just an example!
I had the same problem with a few functions as well. It turned out that the argument was, after several typedefs, an __int64, which is not defined (not standard). I only had to define it in my project and this solved the problem.
Project->Properties->C/C++ General->Paths and Symbols->Symbols->C++ Source File->add
name: __int64
value: long long
(or instead of "long long" maybe you could use one of the values from this answer)
Edit:
By the way, I saw a bug report about this very issue in the Eclipse bugzilla, so maybe defining __int64 won't be necessary in the future