What should I use on linux > 2.6.28 instead of __arch__swab32 - linux-kernel

I keep getting compilation error for a kernel module:
XXX: In function 'yyy':
ZZZ:125: error: implicit declaration of function '__arch__swab32'
PowerPC, 2.6.30.x, Kamikaze toolchain. According to this the identifier went away after 2.6.28. What should I use instead?

You should be using the generic __swab32 from linux/swab.h (which also exists on earlier kernel versions).

Related

How can I specify a minimum compute capability to the mexcuda compiler to compile a mexfunction?

I have a CUDA project in a .cu file that I would like to compile to a .mex file using mexcuda. Because my code makes use of the 64-bit floating point atomic operation atomicAdd(double *, double), which is only supposed for GPU devices of compute capability 6.0 or higher, I need to specify this as a flag when I am compiling.
In my standard IDE, this works fine, but when compiling with mexcuda, this is not working as I would like. In this post on MathWorks, it was suggested to use the following command (edited from the comment by Joss Knight):
mexcuda('-v', 'mexGPUExample.cu', 'NVCCFLAGS=-gencode=arch=compute_60,code=sm_60')
but when I use this command on my file, the verbose option spits out the following line last:
Building with 'NVIDIA CUDA Compiler'.
nvcc -c --compiler-options=/Zp8,/GR,/W3,/EHs,/nologo,/MD -
gencode=arch=compute_30,code=sm_30 -gencode=arch=compute_50,code=sm_50 -
gencode=arch=compute_60,code=sm_60 -
gencode=arch=compute_70,code=\"sm_70,compute_70\"
(and so on), which signals to me that the specified flag was not passed to the nvcc properly. And indeed, compilation fails with the following error:
C:/path/mexGPUExample.cu(35): error: no instance of overloaded function "atomicAdd" matches
the argument list. Argument types are: (double *, double)
The only other post I could find on this topic was this post on SO, but it is almost three years old and seemed to me more like a workaround - one which I do not understand even after some research, otherwise I would have tried it - rather than a true solution to the problem.
Is there a setting I missed, or can this simply not be done without a workaround?
I was able to work my way around this problem after some messing around with the standard xml-files in the MatLab folder. The following steps allowed me to compile using -mexcuda:
-1) Go to the folder C:\Program Files\MATLAB\-version-\toolbox\distcomp\gpu\extern\src\mex\win64, which contains xml-files for different versions of msvcpp;
-2) Make a backup of the file that corresponds to the version you are using. In my case, I made a copy of the file nvcc_msvcpp2017 and named it nvcc_msvcpp2017_old, to always have the original.
-3) Open nvcc_msvcppYEAR with notepad, and scroll to the following block of lines:
COMPILER="nvcc"
COMPFLAGS="--compiler-options=/Zp8,/GR,/W3,/EHs,/nologo,/MD $ARCHFLAGS"
ARCHFLAGS="-gencode=arch=compute_30,code=sm_30 -gencode=arch=compute_50,code=sm_50 -gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_70,code=\"sm_70,compute_70\" $NVCC_FLAGS"
COMPDEFINES="--compiler-options=/D_CRT_SECURE_NO_DEPRECATE,/D_SCL_SECURE_NO_DEPRECATE,/D_SECURE_SCL=0,$MATLABMEX"
MATLABMEX="/DMATLAB_MEX_FILE"
OPTIMFLAGS="--compiler-options=/O2,/Oy-,/DNDEBUG"
INCLUDE="-I"$MATLABROOT\extern\include" -I"$MATLABROOT\simulink\include""
DEBUGFLAGS="--compiler-options=/Z7"
-4) Remove the architectures that will not allow your code to compile, i.e. all the architecture flags below 60 in my case:
ARCHFLAGS="-gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_70,code=\"sm_70,compute_70\" $NVCC_FLAGS"
-5) I was able to compile using mexcuda after this. You do not need to specify any architecture flags in the mexcuda call.
-6) (optional) I suppose you want to revert this change after you are done with the project that required you to make this change, if you want to ensure maximum portability of the code you will compile after this.
Note: you will need administrator permission to make these changes.

go-guru on linux code in non-linux system

We use docker and so the source code is for linux code. However, we develop on Macs, and as a result go-guru-callers fails to work when run locally.
It complains with the error below but the error is because that property is linux specific:
/Users/uri/Documents/connect/src/connect/job/native.go:104:4: unknown field Pdeathsig in struct literal
and the code:
cmd.SysProcAttr = &syscall.SysProcAttr{
Pdeathsig: syscall.SIGKILL,
}
Any workarounds?
You can use build conditions to specify what code should be built on what OS and architecture, in order to separate out code that is platform-specific and avoid these kinds of compilation failures. See the go build documentation here.

Compile error for Linux kernel 4.10.8 targeting ARM

I'm trying to cross compile the Linux kernel 4.10.8 for arm, but get this error:
CC [M] drivers/vhost/vhost.o
In file included from ./include/uapi/linux/stddef.h:1:0,
from ./include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from ./include/uapi/linux/types.h:13,
from ./include/linux/types.h:5,
from ./include/uapi/asm-generic/fcntl.h:4,
from ./arch/arm/include/uapi/asm/fcntl.h:9,
from ./include/uapi/linux/fcntl.h:4,
from ./include/linux/fcntl.h:4,
from ./include/linux/eventfd.h:11,
from drivers/vhost/vhost.c:14:
drivers/vhost/vhost.c: In function ‘vhost_vring_ioctl’:
./include/linux/compiler.h:518:38: error: call to ‘__compiletime_assert_1357’ declared with attribute error: BUILD_BUG_ON failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)enter
Any idea how to solve this?
I dont know what this module is used for, so I dont know if I actually need to compile it, but I cant find where in menuconfig to disable this module?
This module (CONFIG_VHOST) usually requires when you need virtualization support. If you don't require it disable it in the make menuconfig.
If you don't need virtualization, you can ignore it and proceed your build.

Can't compile CapacitiveSensor example in Arduino

I am trying to use the Capacitive Sensors Library from the Arduino Playground with Arduino 1.5.3 for Intel Galileo.
While trying to compile the example Sketch of the library with nothing touched I get the following error:
Arduino: 1.5.3 (Windows 7), Board: "Intel® Galileo"
CapacitiveSensor.cpp: In constructor
'CapacitiveSensor::CapacitiveSensor(uint8_t, uint8_t)':
CapacitiveSensor.cpp:30:63: error: 'F_CPU' was not declared in this
scope CapacitiveSensor.cpp:43:10: error: 'PinDescription' has no
member named 'ulPin' CapacitiveSensor.cpp:44:10: error:
'PinDescription' has no member named 'pPort'
CapacitiveSensor.cpp:45:31: error: 'portModeRegister' was not declared
in this scope CapacitiveSensor.cpp:46:9: error: base operand of '->'
is not a pointer CapacitiveSensor.cpp:48:9: error: 'PinDescription'
has no member named 'ulPin' CapacitiveSensor.cpp:49:10: error:
'PinDescription' has no member named 'pPort'
CapacitiveSensor.cpp:51:9: error: base operand of '->' is not a
pointer CapacitiveSensor.cpp:52:12: error: base operand of '->' is not
a pointer CapacitiveSensor.cpp:55:18: error: 'noInterrupts' was not
declared in this scope CapacitiveSensor.cpp:57:16: error: 'interrupts'
was not declared in this scope CapacitiveSensor.cpp: In member
function 'void CapacitiveSensor::set_CS_Timeout_Millis(long unsigned
int)': CapacitiveSensor.cpp:133:73: error: 'F_CPU' was not declared in
this scope CapacitiveSensor.cpp: In member function 'int
CapacitiveSensor::SenseOneCycle()': CapacitiveSensor.cpp:141:18:
error: 'noInterrupts' was not declared in this scope
CapacitiveSensor.cpp:151:16: error: 'interrupts' was not declared in
this scope
I downloaded the files and imported the "CapacitiveSensor"-Folder into (I did those steps one after the other, not at the same time.):
The libraries folder under Documents/arduino/.
The libraries folder in the arduino folder where the arduino.exe is stored.
Onto arduino-1.5.3/hardware/libraries/ (because this is mentioned on the site where I downloaded it)
And I tried this: Here Because it seemed to be the same error as I had. But it didnt work.
I also deleted my Arduino and reinstalled it.
Anyone has an Idea?
Thanks in advance,
Clemens
There is a similar question on the Arduino forum but I don't know if your issue is exactly the same: [FIXED][CapacitiveSensor] Can't compile with Due (port manipulation)
It doesn't look like the Arduino folks are very responsive. The user modified register names and eventually put his own library out there.
*"...changed the uint8_t registers to RwReg (compiler doesn't complain) and I replaced the use of portModeRegister(PIN) with simple pinMode(PIN, MODE) calls (it's slower but it works)."*

Why does GDB says "Architecture of file not recognized"?

I m using gdb on a aix shared lib running on aix 5.3?
When i try to run gdb for this file
i get a error message saying ""Architecture of file not recognized"
Don't know how to get this fixed.
Does anybody know why i get this message ""Architecture of file not recognized"?.
gdb runs fine on other executables compiled by xlc.
Is there some option that i might have used while compiling , which is not compatible with GDB.some processor specific option.
I compiled the shared lib w xlc v9.0 for aix.
Thanks.
You don't run GDB on a shared library, you run it on an executable.
If the executable loads your shared library, GDB will know about it.
void
set_gdbarch_from_file (bfd *abfd)
{
struct gdbarch_info info;
struct gdbarch *gdbarch;
gdbarch_info_init (&info);
info.abfd = abfd;
info.target_desc = target_current_description ();
gdbarch = gdbarch_find_by_info (info);
if (gdbarch == NULL)
error (_("Architecture of file not recognized."));
deprecated_current_gdbarch_select_hack (gdbarch);
}
This is the actual GDB code in question (gdb/arch-utils.c:530-544).
The information passed to the gdbarch pointer seems to be invalid. This is caused by gdb_find_by_info returning a NULL pointer and that is caused by find_arch_by_info (gdb/gdbarch.c:3656) returning a NULL pointer.
It basically means what it says: GDB could not identify the architecture of the file. This seems to be a common problem for xlc, even on recent gdb versions.
XLC and gdb are, as far i remember and understand, not very good when it comes down to compatability terms (AIX support is minimal), you might try using the Gnu C Compiler .You might look at the GDB sources for VERY specific information (that i can't really give you).
Here is a link to gcc-AIX specifics.

Resources