I need to get the processor number in my program with C/C++ language. My code
like as follow:
#include <unistd.h>
int main()
{
int processorNum = sysconf(_SC_NPROCESSORS_CONF);
return 0;
}
when i compile it , it had two errors:
error: '_SC_NPROCESSORS_CONF' was not declared in this scope
error: 'sysconf' was not declared in this scope
so ,what should i do.
ps: my complier's version is gcc version 4.3.2 (Debian 4.3.2-1.1).should i link a library file
ps: Hi all, excuse me ,i made some mistakes. i forgot the head file.
1、The most reliable way is to read /proc/cpuinfo file. like grep processor proc/cpuinfo
2、use command lscpu
Related
In my project I am using char driver to communicate between user space and kernel space. I use the function copy_to_user(void user *to, const void *from, unsigned long n) to copy data from kernel space to user space buffer. We can find this function under #include < asm/uaccess.h > header file.
I complied the project using Linux Kernel version 4.4.0-59-generic, Ubuntu OS version 16.04 LTS and its working fine without any error and warning. I get the desired output.
I compiled the same project using Linux kernel version 4.12.8, Ubuntu OS version 16.04.2 LTS and it throws me an warning during compile time WARNING: "copy_to_user" [/home/ldrv1/Desktop/Vijay/code/build/uts.ko] undefined!. When I do insmod of my module I get error as follows insmod: ERROR: could not insert module uts.ko: Unknown symbol in module. I think that #include <asm/uaccess.h> header file is still supported in 4.12.8 kernel version else I would have got fatal error: no such file or directory error while compiling. I tried updating the linux kernel headers using apt-get install linux-headers-$(uname -r) command and I got the following response:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-headers-4.12.8
E: Couldn't find any package by glob 'linux-headers-4.12.8'
E: Couldn't find any package by regex 'linux-headers-4.12.8'
This OS version 16.04.2 LTS has linux-headers-4.10.0-35.
How do I get rid of this warning? Suggestions and support appreciated. If more information is required please feel free to ask.
You should use #include <linux/uaccess.h> for 4.12.8.
Here is the definition.
In 4.4 some drivers use #include <asm/uaccess.h> whilst the others
use #include <linux/uaccess.h>.
#include <linux/uaccess.h> is preferable, I think.
You should do apt-get update and then apt-get install linux-headers-generic.
The function copy_to_user and copy_from_user defined in asm/uaccess.h . I think you have some issue when you define this function. I wrote the character device driver with some example about data transfer between Kernel space and User space. View my github: my code for reference. Please star if you feel it is helpful for you :). it has small bug in example 3. I am figuring them, but example 1 and example 2 work well
The answer given by Bronislav Elizaveti is correct. If instead of #include <asm/uaccess.h> we use #include <linux/uaccess.h>, then we won't get the warning.
If you still want to use only #include <asm/uaccess.h>, then you'll need to use _copy_to_user instead of copy_to_user (with the same arguments). A simple _ will do the job.
If I define a symbol address when linking a program on Ubuntu 16.10, this doesn't seem to produce the correct address when running the program. For example taking the following program
#include <stdio.h>
extern int mem_;
int main()
{
printf("%p\n", &mem_);
}
and compiling with
gcc example.c -o example -Xlinker --defsym=mem_=0x80
then running the program prints 0x80 on older Ubuntu systems, but a random number on Ubuntu 16.10. The 0x80 symbol seems to go into the executable, as shown by the nm program, however.
Any ideas what's causing this? I'm suspecting a security feature.
Under the GCC section of the ChangeLog (found here: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes)
"We have modified GCC to by-default compile programs with position independent executable support, on the amd64 and ppc64el architectures, to improve the security benefits provided by Address Space Layout Randomization."
To disable this option, simply add -no-pie to GCC's flags.
I'm running Linux on spike as described at: http://riscv.org/download.html#tab_linux. With busybox I have a powerful tool to run several usefull tools. The next thing I am trying to achieve, is to run my own program on riscv/Linux. Therefore I wrote a little program:
#include <stdio.h>
int main(void) {
printf("Hello world!\n");
return 0; }
compiled it with riscv64-unknown-linux-gnu-gcc and added the binary to the root.img of riscv/Linux. The Problem I now have is, that if I want to execute the program under riscv/Linux threw ./hello, the following message appears on my shell:
-/bin/ash: ./hello: not found
My Question now is (1) what am I doing wrong and (2) is there at all a possibility to run a program on riscv/Linux the way I am trying accomplish it?
My guess is that your hello program is dynamically linked to a runtime library that is missing from your root file system.
You can use 'ldd' to find which dynamic libraries your application is linked with and make sure all of them are present on the root file system or simply compile the hello program statically.
I am porting a Windows VC++ application to Linux that links to an assembler module currently produced by MASM. After changing its Windows ABI assumptions to Linux ABI, I would like to again assemble the module on MASM to OMF (in Windows), then directly input that object file into the GCC build (in Linux). This would greatly simplify maintenance over time and guarantee an identical assembly under both operating systems. The alternative is porting the assembler code to YASM/NASM and its complications. The assembler code is entirely leaf routines (no calls), with no macros, no Unicode data and scant integer/real data; it includes 32-bit and a 64-bit assembler versions. Barring endian issues, does it really matter whose tool chain generates the OMF representation for this module?
I tested out it out using a simple test case and it worked fine when linked using the GNU linker under Linux. So you probably don't need to do anything special.
Here's the assembly file I tested it with:
_TEXT SEGMENT USE32
PUBLIC foo
foo:
mov eax, 1234
ret
_TEXT ENDS
END
And here's the C program:
#include <stdio.h>
extern int foo();
int
main() {
printf("%d\n", foo());
return 0;
}
I assembled the first file on Windows using MASM, copied the resulting .OBJ file to a Linux machine (Debian x86_64) and compiled/linked it with the following command:
gcc -m32 main.c foo.obj
Running the generated executable (a.out) produced the expected output: 1234. I also tested the equivalent 64-bit case and it worked as well.
Unless you're dependent on PECOFF-specific section (segment) ordering or other PECOFF-specific features it looks like you shouldn't have any problems, at least far the object file format goes. Note it's possible that the version of the GNU linker installed on your Linux machine wasn't built with support for PECOFF. In that case you may need to build your own version from source.
i am trying to know the size of task_struct. thus i have downloaded the linux source code from the website and i have generated the head files via typing the command make headers_install into terminal in the source code file root directory.
#include<stdio.h>
#include<linux/sched.h>
int main()
{
printf("%d\n",sizeof(struct task_struct)).
return 0;
}
typing the command to the termial to compile and source code gcc -g -I *path/to/linux*-source/usr/include test.c -o test. However the terminal shows struct task_struct does not define stuff.
Could any guys to help me to figure it out? Really appreciated.
This struct is for kernel internal use only. It's definition is pretty long and largely varies depending on kernel configuration. So, the struct size also varies depending on kernel configuration, and you can't get it from user-space.
Unless, you extract kernel config, which is bad idea, as for me. The better one is to write a kernel module.