I want to change PAGE_SIZE from 4096 for the experiment. So I changed the value of PAGE_SHIFT in /arch/x86/include/asm/page_types.h. But I can't compile it.
In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from include/linux/cache.h:4,
from include/linux/time.h:4,
from arch/x86/kernel/vsyscall_64.c:23:
arch/x86/kernel/vsyscall_64.c: function ‘map_vsyscall’ 内:
include/linux/compiler.h:437:20: eroor: call to ‘compiletime_assert_390’ declared with attribute error: BUILD_BUG_ON failed: (unsigned long)__fix_to_virt(VVAR_PAGE) != (unsigned long)VVAR_ADDRESS
prefix ## suffix(); \
^
include/linux/compiler.h:442:2: note: in expansion of macro ‘__compiletime_assert’
__compiletime_assert(condition, msg, prefix, suffix)
^
include/linux/compiler.h:454:2: note: in expansion of macro ‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE)
^
include/linux/bug.h:53:37: note: in expansion of macro ‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
include/linux/bug.h:77:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^
arch/x86/kernel/vsyscall_64.c:389:2: note: in expansion of macro ‘BUILD_BUG_ON ’
BUILD_BUG_ON((unsigned long)__fix_to_virt(VVAR_PAGE) !=
^
make[2]: * [arch/x86/kernel/vsyscall_64.o] eroor 1
make[1]: * [arch/x86/kernel] error 2
make: *** [arch/x86] error 2
Probably due to VVAR_PAGE, but I don't know how to change it.
What should i do?
You can't directly modify the PAGE_SIZE by setting PAGE_SHIFT as it is generated at compile-time.
Assuming your processor is a x86, you can modify your page size up to 8k with the family of variables CONFIG_PAGE_SIZE_XXX such as CONFIG_PAGE_SIZE_8KB. Note that using big pages will take a lot of space unnecessarily as even 1-byte files takes a full page on disk. Also, changing the page size is architecture dependant and it is recommended to keep the default 4K size.
A better approach though, might be to use huge pages, more flexible and more powerful. They are presented there
Related
I am new to autoconf so I would ask you how could I check if a struct member is declared with a particular type.
For example I should check if struct posix_acl.a_refcount is declared as refcount_t and not atomic_t.
I know AC functions as ac_fn_c_check_decl and ac_fn_c_check_member, but none that accomplish this task.
Thank you!
Disclaimer: As there are no other answers at the time this answer is being written, this represents my best attempt to provide a solution, but you may need to adjust things to make it work for you. Caveat emptor.
You would need to use the AC_COMPILE_IFELSE macro with code that uses atomic_t, and if the compilation succeeds, then you're using atomic_t. As future-proofing, you might also add a test for refcount_t if the atomic_t test fails.
Example:
# _POSIX_ACL_REFCOUNT_T(type-to-check)
# ------------------------------------
# Checks whether the Linux kernel's `struct posix_acl'
# type uses `type-to-check' for its `a_refcount' member.
# Sets the shell variable `posix_acl_refcount_type' to
# `type-to-check' if that type is used, else the shell
# variable remains unset.
m4_define([_POSIX_ACL_REFCOUNT_T], [
AC_REQUIRE([AC_PROG_CC])
AC_MSG_CHECKING([whether struct posix_acl uses $1 for refcounts])
AC_COMPILE_IFELSE(
[AC_LANG_SOURCE(
[#include <uapi/../linux/posix_acl.h>
struct posix_acl acl;
$1 v = acl.a_refcount;]
)],
[AC_MSG_RESULT([yes])
AS_VAR_SET([posix_acl_refcount_type], [$1])],
[AC_MSG_RESULT([no])
)
])
_POSIX_ACL_REFCOUNT_T([atomic_t])
# If posix_acl_refcount_type isn't set, see if it works with refcount_t.
AS_VAR_SET_IF([posix_acl_refcount_type],
[],
[_POSIX_ACL_REFCOUNT_T([refcount_t])]
)
dnl
dnl Add future AS_VAR_SET_IF tests as shown above for the refcount type
dnl before the AS_VAR_SET_IF below, if necessary.
dnl
AS_VAR_SET_IF([posix_acl_refcount_type],
[],
[AC_MSG_FAILURE([struct posix_acl uses an unrecognized type for refcounts])]
)
AC_DEFINE([POSIX_ACL_REFCOUNT_T], [$posix_acl_refcount_type],
[The type used for the a_refcount member of the Linux kernel's posix_acl struct.])
The tests assume that you already have a variable containing the kernel source directory, and the kernel source's include directory is specified in CPPFLAGS or CFLAGS prior to attempting the tests. You can add more tests at the position indicated, and if the resulting posix_acl_refcount_type shell variable is still not defined after all those tests, then the final AS_VAR_SET_IF invocation will invoke AC_MSG_FAILURE to stop configure with the specified error message.
Note that I used <uapi/../linux/posix_acl.h> to specifically target the kernel's linux/posix_acl.h header rather than the userspace API uapi/linux/posix_acl.h header installed in a system's include directory with the uapi/ stripped off, which may result in the compile tests above failing due to the missing struct posix_acl in the userspace API. This may not work the way I'd expect and may need modification.
Using ModelSim and VUnit I try to compile some UVVM, but this gives some warnings like:
** Warning: C:\work\Qtec\SVN_sim\Design\uvvm\uvvm_util\src\methods_pkg.vhd(1159): (vcom-1346) Default expression of interface object is not globally static.
So I would like to suppress these warnings, so I tried updating the VUnit "run.py" file with add_compile_option based on VUnit Python Interface:
uvvm_util = prj.add_library('uvvm_util')
uvvm_util.add_source_files(join(root, '../../uvvm/uvvm_util/src/*.vhd'))
uvvm_util.add_compile_option('modelsim.vcom_flags', ['-suppress 1346'])
But when compiling, I then get the error:
Compiling ....\uvvm\uvvm_util\src\types_pkg.vhd into uvvm_util ...
** Error (suppressible): (vcom-1902) Option "-suppress 1346" is either unknown, requires an argument, or was given with a bad argument.
You could edit the suppress entry in the modelsim.ini file. source
It could be a python/TCL error with spaces. See this link.
So the space between -suppress and 1346 is not properly forwarded.
The VUnit ui.py shows
modelsim.vcom_flags
Extra arguments passed to ModelSim vcom command.
Must be a list of strings.
I cannot test it, but this case the line should possibly be:
uvvm_util.add_compile_option('modelsim.vcom_flags', ['-suppress', '1346'])
edit: after some reading... To me the difference between add_compile_option and set_compile_option is not clear. Maybe you could try the other?
So I am using Visual Studio 2015 and some online library I found,and in the sample project everything is working, but when i make my own, I get errors.
Errors are found in file cmath.
When i build my project i get
'abs' , 'pow' , 'abs' , 'acos' , ..., second C linkage of overloaded function not allowed.
How can i fix this ? I tried setting
Properties->General->Project Defaults -> Character set to Use Multi-Byte Character Set or No set, but still get errors.
Thanks !
Note 1:
It looks like inside file cmath there are two functions of each mathematical function that make problem like:
_Check_return_ inline double abs(_In_ double _Xx) _NOEXCEPT
{
return (_CSTD fabs(_Xx));
}
_Check_return_ inline float abs(_In_ float _Xx) _NOEXCEPT
{
return (_CSTD fabsf(_Xx));
}
Why are there two of these functions and why would this represent a problem ?
File was .cpp and library was for C. So this made some errors, after changing extension of file to .c errors dissapeared
I am using a Lua script to determine the file size:
local filesize=0
local filePath = "somepath.bin"
local file,msg = io.open(filePath, "r")
if file then
filesize=file:seek("end")
file:close()
filePresent = true
end
However, this only seem to work for files up to 2GB. For larger files filesize is always nil. Is there any limitation on io.open? And if so, how could I work around this?
Running Lua 5.1.4 on Windows Server 2008 R2 64bit
The problem is not in io.open, but file:seek. You can check the error like this:
filesize, err = file:seek("end")
if not filesize then
print(err)
end
The error message is probably Invalid argument. That's because for files larger than 2GB, its size is over what 32-bit long can hold, which causes the C function fseek fail to work.
In POSIX systems, Lua uses fseeko which takes the size of off_t instead of long in fseek. In Windows, there's a _fseeki64 which I guess does similar job. If these are not available, fseek is used, and it would cause the problem.
The relevant source is liolib.c(Lua 5.2). As #lhf points out, in Lua 5.1, fseek is always used (source). Upgrading to Lua 5.2 could possibly solve the problem.
Internally, Lua uses the ISO C function long int ftell(FILE *stream); to determine the return value for file:seek(). A long int is always 32 bits on Windows, so you are out of luck here. If you can, you should use some external library to detect the file size -- I recommend luafilesystem.
On old Lua versions (where file:seek() is limited to 2Gb) you can ask cmd.exe to get file size:
function filesize(filename)
-- returns file size (or nil if the file doesn't exist or unable to open)
local command = 'cmd /d/c for %f in ("'..filename..'") do #echo(%~zf'
return tonumber(io.popen(command):read'*a')
end
print(filesize[[C:\Program Files\Windows Media Player\wmplayer.exe]])
--> 73728
print(filesize[[E:\City.of.the.Living.Dead.1980.720p.BluRay.x264.Skazhutin.mkv]])
--> 8505168882
I'm using MSVC++ to program a simple window, and I included a resource file for a menu along the lines of:
MYMENU MENU DISCARDABLE
//etc.
and I created a header file "resourcedef.h" with definitions like
#define ID_MYMENU_FILE_CLOSE 1002
I can include it in my main.cpp file without error, however, when I include it in the resource file, I get the error
.\resourcedef.h(9) : fatal error RC1004: unexpected end of file found
(resourcedef.h is exactly 9 lines long). When I add a newline the the end of the .h,
//lines 1 - 8
#define ID_MYMENU_FILE_OPEN 1001
So that there is a tenth blank line (that doesn't appear on SO), it compiles fine. If I put anything on the tenth line, even a comment, the compiler gives me an error. Does anyone know what causes this and how I can fix it?
It's a bad idea to omit the trailing newline at the end of a text file - there are many tools that will fail to work properly unless it's there. (Some text editors will even warn you that's it's missing.)
Trailing newlines are standard behaviour for text files - why not go with the flow and just put one there. Everybody else does. 8-)
Long ago, MSVC++ at version 2 or so (1994-ish) would not handle "partial" lines at the end of the file properly. For example:
header.h
#ifndef __HEADER_H
#define __HEADER_H
void foo();
#endif // <-- no newline here
main.cpp
#include "header.h"
#include "other.h"
In this situation, the preprocessor would see the following text after resolving includes:
#ifndef __HEADER_H
#define __HEADER_H
void foo();
#endif#include "other.h"
The bug was that the last line would run together as shown above, and the "other.h" file would not be included. With the IDE at that time, it was easy to accidentally create a file with no trailing newline and run into the above situation.
Fortunately, this bug has long since been fixed. It looks like you've found one of the situations where the compiler warns that it doesn't expect to encounter the end of the file in the middle of a line. This is generally regarded as a good thing.