I took Linux kernel version 4.9.30, added a new directory /fsac whose files include headers from other directory (/include/fsac) and that is almost all I changed. Trying to compile I get a lot of errors in /kernel/sched/core.c that look like this:
kernel/sched/core.c:2326:20: error: invalid storage class for function ‘set_schedstats’
kernel/sched/core.c:2342:19: error: invalid storage class for function ‘setup_schedstats’
(...)
Searching on-line I saw that the recommendation was to simply remove the 'static' from the functions. Doing that effectively avoided that errors, but instead I started getting a lot of warnings from objtool like "frame pointer state mismatch" for each of the functions whose static was removed.
I discovered these warnings can be avoided by changing in the configuration file CONFIG_STACK_VALIDATION=n. That worked but even though there is no warning, compilation fails (Error 2).
Hence, I am wondering:
1 - Is the removal of "static" from the offended functions the proper solution?
2 - If so, how do I deal with the objtool warnings? Can those warnings alone constitute a compilation error, or there must be something else?
3 - Do you think I should degrade GCC?
This is the source code of the project: https://github.com/Zildj1an/FSAC_Kernel
This is the compilation log w/o removing the statics: https://github.com/Zildj1an/FSAC_Kernel/blob/master/build_err
I will happily provide any other information you might need.
Cheers.
Problem found, I had a function inside a function... Probably was moved copying something else.
Related
I'm new to all of this and am trying to compile a program on a virtual machine with kernel version 3.10.0-957.el7.x86_64. But I get this error:
/home/../../../isr_demux.c: In function 'demux0_isr':
/home/../../../ isr_demux.c: 782:3: error: implicit declaration of function 'rdtscl' [-Werror=implicit-function-declaration]`
I pulled up isr_demux.c and saw that the snippet of code it said was causing the error is this:
The third to last line is line 782. What's interesting is that this same file compiles fine on a virtual machine with an older kernel version 3.10.0-327.el7.x86_64.
I searched online a lot but am truly stuck. I saw another post and checked my header files, and included linux/proc_fs.h along with many other ones. Someone said I could be missing a function prototype or definition, but adding a prototype did not fix this, and defining the function led to a redefinition error.
Any ideas about whether I'm still missing a header file somewhere? Or if the problem is with the newer kernel itself and I might need to find some sort of patch? Thanks!
The website elixir.bootlin.com is pretty useful for these things. The following link is a search across the entire kernel sources tree for version 3.10.108 for the symbol rdtscl.
https://elixir.bootlin.com/linux/v3.10.108/ident/rdtscl
rdtscl is only defined as a macro, so looks like the macro is not defined where you are getting your error about implicit declaration of rdtscl.
The two places where rdtscl is defined as a macro are:
https://elixir.bootlin.com/linux/v3.10.108/source/arch/x86/include/asm/msr.h#L182
https://elixir.bootlin.com/linux/v3.10.108/source/arch/x86/include/asm/paravirt.h#L182
So the fix is to include the correct headers files if you are building for x86 (the headers defining those macros are in arch/x86), or replace the call to rdtscl with something else.
here my output, I don't understand the hex "0xe8" and "0x7f8c783ac74d";
/home/roroco/Dropbox/rbs/ro_article/c/ro_helper_article.so(get_article_n2+0xe8) [0x7f8c783ac74d]
here is full output
It looks like you've caused (or, rather, a plugin caused) ruby to segfault. This normally means that you've attempted to access memory outside of your designated bounds - basically, your program did something really, really weird. The line you specifically picked out is actually a C library - the .so extension means "static object," and is linked into the main ruby executable. The information it's providing you with tells you where the error originated - however, most production libraries do not contain information such as "file names" and "line numbers". Instead, they contain a list of symbols. In your case, it's telling you exactly where, in the static object, an error originated - exactly 0xe8 bytes after the get_article_n2 symbol - or, at the address 0x7f8c783ac74d.
So now you have a few options.
You can poke around blindly in your source code (I'm assuming you wrote the library that is in error here, since it seems that's what you're testing) and try and guess where the segfault originated. You already know that it's in the function get_article_n2, considering the error originated after that symbol.
You can disassemble the static object to see the specific instruction that caused the error, and then attempt to map it to the source.
You can enable debugging, and have your build system output file names and line numbers so you know what you're looking at. (disclaimer: I'm not sure if this will work; it doesn't look like you're emitting debug information to me, but I'm not sure if you are; and even if you would be, I'm not sure it would be used to output. However, this seems the easiest course of action.).
I have a pretty special problem. I need to review NASA Parallel Benchmarks for my school project, but I found it to be a very problematic task :-) At first, I tried to work with IS (integer sort), but the code wasn't able to compile, and I found out, that I need to rewrite make.def file. So I rewrote it's variable for mpi.h and compiled it, but the program keeps alerting me:
Fatal error in PMPI_Comm_rank: Invalid communicator, error stack:
PMPI_Comm_rank(108): MPI_Comm_rank(comm=0x0, rank=0x6084e8) failed
PMPI_Comm_rank(66).: Invalid communicator
To be honest, I don't really know, should I do know. I tried even changing the old compilers, like cc to gcc etc. but it doesn't seem to have any effect. Last thing which I tried to rewrite was the variable CMPI_LIB, but I have no idea how to do it correctly.
Thank you very much for all your responses ;-)
And I'm sorry for my bad English, I'm not a native speaker.
The whole benchmark is here for download (cca 600kB): uloz.to/xTSEzTX8/npb3-3-1-zip
File is.c which I'm trying to compile and launch: hostcode.sourceforge.net/view/2436
Makefile: hostcode.sourceforge.net/view/2437
File make.common - takes care of compiling files with special functions etc.: hostcode.sourceforge.net/view/2438
My make.def is here: #veeylg84-46196 - BASH - Sourcecode
Structure of files in my 'benchmark folder': http://www.sourcepod.com/sozaoh48-46200
The PMPI_Comm_rank(108): MPI_Comm_rank(comm=0x0, rank=0x6084e8) failed message tells a lot. Your MPI_COMM_WORLD constant is 0 which is not the case with MPICH-based (as one could guess from the format of the error message) implementations. It is a compile-time constant in MPICH (#define MPI_COMM_WORLD ((MPI_Comm)0x44000000)) and a run-time constant reference in Open MPI. The #1 reason for such errors is mixing MPI implementations, i.e. including mpi.h from one implementation and linking against the libraries of another one.
As evident from your make.def, you are including mpi.h from a dummy MPI implementation and linking against a real MPI library. This simply won't work. Since mpicc takes care of passing the right include paths and library options to the backend compiler, you don't have to set CMPI_LIB or CMPI_INC explicitly and should leave them empty instead. Those are reserved for the case when the MPI implementation does not provide compiler wrappers (mpicc, mpif90, etc.) and one has to explicitly specify all options, which is the case with e.g. MS-MPI.
I am new to delphi. I was trying to add C Object files in my Delphi project and link them directly since Delphi Supports C Object Linking. I got it working when i link a single Object file. But when i try to link multiple object files, i am getting error 'Unsatisfied forward or external declaration'. I have tried this in Delphi 2007 as well as XE.So what am i doing wrong here?
Working Code:
function a_function():Integer;cdecl;
implementation
{$Link 'a.obj'}
function a_function():Integer;cdecl;external;
end.
Error Code:
function a_function():Integer;cdecl;
function b_function();Integer;cdecl;
function c_function();Integer;cdecl;
implementation
{$LINK 'a.obj'}
{$LINK 'b.obj'}
{$LINK 'c.obj'}
function a_function():Integer;cdecl;external;
function b_function();Integer;cdecl;external;
function c_function();Integer;cdecl;external;
end.
As an aside, the article linked by #vcldeveloper has a good explanation of some of the common issues. The trick of providing missing C RTL functions in Pascal code is excellent and much quicker than trying to link in the necessary functions as C files, or even as .obj files.
However, I have a suspicion that I know what is going on here. I use this same approach but in fact have over 100 .obj files in the unit. I find that when I add new ones, I get the same linker error as you do. The way I work around this is to try re-ordering my $LINK instructions. I try to add the new obj files one by one and I have always been able, eventually, to get around this problem.
If your C files are totally standalone then you could put each one in a different unit and the linker would handle that. However, I doubt that is the case and indeed I suspect that if they really were standalone then this problem would not occur. Also, it's desirable to have the $LINK instructions in a single unit so that any RTL functions that need to be supplied can be supplied once and once only (they need to appear in the same unit as the $LINK instructions).
This oddity in the linker was present in Delphi 6 and is present in Delphi 2010.
EDIT 1: The realisation has now dawned on me that this issue is probably due to Delphi using a single pass compiler. I suspect that the "missing external reference" error is because the compiler processes the .obj files in the order in which they appear in the unit.
Suppose that a.obj appears before b.obj and yet a.obj calls a function in b() b.obj. The compiler wouldn't know where b() resides at the point where it needs to fixup the function call. When I find the time, I going to try and test if this hypothesis is at the very least plausible!
Finally, another easy way out of the problem would be to combine a.c, b.c and c.c into a single C file which would I believe bypass this issue for the OP.
Edit 2: I found another Stack Overflow question that covers this ground: stackoverflow.com/questions/3228127/why-does-the-order-of-linked-object-file-with-l-directive-matter
Edit 3: I have found another truly wonderful way to work around this problem. Every time the compiler complains
[DCC Error] Unit1.pas(1): E2065 Unsatisfied forward or external declaration: '_a'
you simply add, in the implementation section of the unit, a declaration like so:
procedure _a; external;
If it is a routine that you wish to call from Delphi then you clearly need to get the parameter list, calling conventions etc. correct. Otherwise, if it is a routine internal to the external code, then you can ignore the parameter list, calling conventions etc.
To the best of my knowledge this is the only way to import two objects that refer to each other in a circular manner. I believe that declaring an external procedure in this way is akin to making a forward declaration. The difference is that the implementation is provided by an object rather than Pascal code.
I've now been able to add a couple of more tools to my armory – thank you for asking the question!
Shouldn't be hard, right? Right?
I am currently trawling the OpenAFS codebase to find the header definition of pioctl. I've thrown everything I've got at it: checked ctags, grepped the source code for pioctl, etc. The closest I've got to a lead is the fact that there's a file pioctl_nt.h that contains the definition, except it's not actually what I want because none of the userspace code directly includes it, and it's Windows specific.
Now, I'm not expecting you to go and download the OpenAFS codebase and find the header file for me. I am curious, though: what are your techniques for finding the header file you need when everything else fails? What are the worst case scenarios that could cause a grep for pioctl in the codebase to not actually come up with anything that looks like a function definition?
I should also note that I have access to two independent userspace programs that have done it properly, so in theory I could do an O(n) search for the function. But none of the header files pop out to me, and n is large...
Edit: The immediate issue has been resolved: pioctl() is defined implicitly, as shown by this:
AFS.xs:2796: error: implicit declaration of function ‘pioctl’
If grep -r and ctags are failing, then it's probably being defined as the result of some nasty macro(s). You can try making the simplest possible file that calls pioctl() and compiles successfully, and then preprocessing it to see what happens:
gcc -E test.c -o test.i
grep pioctl -C10 test.i
There are compiler options to show the preprocessor output. Try those? In a horrible pinch where my head was completely empty of any possible definition the -E option (in most c compilers) does nothing but spew out the the preprocessed code.
Per requested information: Normally I just capture a compile of the file in question as it is output on the screen do a quick copy and paste and put the -E right after the compiler invocation. The result will spew preprocessor output to the screen so redirect it to a file. Look through that file as all of the macros and silly things are already taken care of.
Worst case scenarios:
K&R style prototypes
Macros are hiding the definition
Implicit Declaration (per your answer)
Have you considered using cscope (available from SourceForge)?
I use it on some fairly significant code sets (25,000+ files, ranging up to about 20,000 lines in a file) with good success. It takes a while to derive the file list (5-10 minutes) and longer (20-30 minutes) to build the cross-reference on an ancient Sun E450, but I find the results useful.
On an almost equally ancient Mac (dual 1GHz PPC 32-bit processors), cscope run on the OpenAFS (1.5.59) source code comes up with quite a lot of places where the function is declared, sometimes inline in code, sometimes in headers. It took a few minutes to scan the 4949 files, generating a 58 MB cscope.out file.
openafs-1.5.59/src/sys/sys_prototypes.h
openafs-1.5.59/src/aklog/aklog_main.c (along with comment "Why doesn't AFS provide these prototypes?")
openafs-1.5.59/src/sys/pioctl_nt.h
openafs-1.5.59/src/auth/ktc.c includes a define for PIOCTL
openafs-1.5.59/src/sys/pioctl_nt.c provides an implementation of it
openafs-1.5.59/src/sys/rmtsysc.c provides an implementation of it (and sometimes afs_pioctl() instead)
The rest of the 184 instances found seem to be uses of the function, or documentation references, or release notes, change logs, and the like.
The current working theory that we've decided on, after poking at the preprocessor and not finding anything either, is that OpenAFS is letting the compiler infer the prototype of the function, since it returns an integer and takes pointer, integer, pointer, integer as its parameters. I'll be dealing with this by merely defining it myself.
Edit: Excellent! I've found the smoking gun:
AFS.xs:2796: error: implicit declaration of function ‘pioctl’
While the original general question has been answered, if anyone arrives at this page wondering where to find a header file that defines pioctl:
In current releases of OpenAFS (1.6.7), a protoype for pioctl is defined in sys_prototypes.h. But that the time that this question was originally asked, that file did not exist, and there was no prototype for pioctl visible from outside the OpenAFS code tree.
However, most users of pioctl probably want, or are at least okay with using, lpioctl ("local" pioctl), which always issues a syscall on the local machine. There is a prototype for this in afssyscalls.h (and these days, also sys_prototypes.h).
The easiest option these days, though, is just to use libkopenafs. For that, include kopenafs.h, use the function k_pioctl, and link against -lkopenafs. That tends to be a much more convenient interface than trying to link with OpenAFS libsys and other stuff.
Doesn't it usually say in the man page synopsis?