I found a sample of simple kernel loader and try to get how it works. But I can't even build it due to errors:
loader.s:5:20: error: unexpected token in '.section' directive
.section .multiboot
^
loader.s:11:15: error: unexpected token in '.section' directive
.section .text
^
loader.s:28:1: error: unknown directive
.sectio .bss
Here is loader code:
.set MAGIC, 0x1badb002
.set FLAGS, (1<<0 | 1<<1)
.set CHECKSUM, -(MAGIC + FLAGS)
.section .multiboot
.long MAGIC
.long FLAGS
.long CHECKSUM
.section .text
.extern main
.extern callConstructors
.global loader
loader:
mov $kernel_stack, %esp
call callConstructors
push %eax
push %ebx
call main
_stop:
cli
hlt
jmp _stop
.sectio .bss
.space 2*1024*1024;
kernel_stack:
I compile it as as -m32 loader.s.
After search I found that I don't need to use .section with .text and .bss but I don't know what's .multiboot section and how to fix this error. I could not find information about .multiboot in Google.
P.S. If it's important I use MacOS.
P.S. If it's important I use MacOS.
That's part of it. Presumably your as is actually the default Apple Clang (LLVM) assembler (check as --version) targeting your host machine. This code was written to be built with a GCC cross-compiler. The code is assuming you're running under an i686-elf cross compiler specifically. I think LLVM and GCC assemblers are pretty interchangeable, but the directives depend on your output target. For you, as/clang/whatever on OSX by default assumes you are compiling for your host machine, which I think doesn't use an ELF output target. Passing -target i686-elf should do the trick.
That said, if you are pushing forward into more meaty OS/kernel dev, there is good reason to build yourself a real cross-compiler. Passing a bunch of flags to your host compiler to force it into cross-compiling is probably going to land you in some pain down the road.
EDIT: I found myself to your question because I'm trying to set up an OS dev environment on my Macbook. If you're building a multiboot kernel you will eventually need to link the above snippet with the real kernel, probably using a linker script. Unfortunately I just found out that Apple's ld doesn't accept GCC-style linker scripts (real ld from LLVM does, so this is an Apple idiosyncrasy), so I'm giving up and just building GCC on my machine. I would recommend that route!
Related
I am working on a CUDA C++ project that uses separable compilation, and I am having some trouble getting a thrust function to compile.
The project builds with no problem until the following function call is added.
thrust::device_ptr<float> max_int = thrust::max_element(
thrust::device_ptr<float>(dev_temp_intensity_buffer),
thrust::device_ptr<float>(dev_temp_intensity_buffer + INT_BUF_SIZE);
As said, I get the build error:
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __fatbinwrap_66_tmpxft_00006db0_00000000_18_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37 referenced in function __cudaRegisterLinkedBinary_66_tmpxft_00006db0_00000000_18_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37 visualize C:\Users\13\Google Drive\WireMeshOT Rafael\CUDA\simulator\build\src\visualize_intermediate_link.obj 1
The funny thing is that this other thrust function call compiles just fine:
thrust::exclusive_scan(thrust::device_ptr<unsigned int>(dev_ray_alive),
thrust::device_ptr<unsigned int>(dev_ray_alive + NRAYS),
thrust::device_ptr<unsigned int>(dev_scanned_alive_rays));
Obs1: dev_temp_intensity_buffer is a float device pointer, and I am including thrust/extrema.h and thrust/device_ptr.h.
Obs2: I am using CMake to configure the build. The relevant CMake code excerpts are shown below.
SET(CUDA_SEPARABLE_COMPILATION ON)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -rdc=true -D_FORCE_INLINES)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -arch=compute_52 -code=sm_52 -lcudart -lcudadevrt -lcuda)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -Xptxas -v)
cuda_add_executable(
project
file1.cu
...)
target_link_libraries (project glut glew)
I finally figured it out!
The linking problem was due to the fact that cudadevrt library was missing. The catch is that only adding -lcudadevrt to the CUDA_NVCC_FLAGS was not enough!
The problem goes away when linking the CUDA runtime device library to the CMake target as shown below:
target_link_libraries(project glut glew ${CUDA_cudadevrt_LIBRARY})
Obs1: the CUDA_cudadevrt_LIBRARY variable is only made available on CMake versions above 3.7.2. Adding the line cmake_minimum_required(VERSION 3.7.2) is a good idea.
Obs2: linking only to CUDA_LIBRARIES as below does solve the issue only if you are using a CMake version above 3.7.2. On lower versions this variable exist but does not contain cudadevrt library.
target_link_libraries(project glut glew ${CUDA_LIBRARIES})
I want to use cmake to compile CUDA with '-arch=sm_12', but cmake/make behave strangely.
I have following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(test)
FIND_PACKAGE(CUDA REQUIRED)
CUDA_ADD_EXECUTABLE(test prog.cu)
SET(CUDA_NVCC_FLAGS "-arch=sm_12")
SET(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} CACHE STRING "Forced" FORCE)
but 'cmake ../src && make' leads to a executable for sm_20.
The flag seems to be ignored.
EDIT: If I call 'make' again (without any modification in CMakeListss.txt) it uses the Flag. - But only if I force the flag to cache (last line)
Am I doing anything wrong?
EDIT: After checking again: I have to call 'make' twice to work correctly. Does anybody know this behaviour?
inJeans was right:
FindCUDA-docs https://cmake.org/cmake/help/v3.3/module/FindCUDA.html
This is the essential information:
"Note that any of these flags can be changed multiple times in the same directory before calling CUDA_ADD_EXECUTABLE, CUDA_ADD_LIBRARY, CUDA_COMPILE, CUDA_COMPILE_PTX, CUDA_COMPILE_FATBIN, CUDA_COMPILE_CUBIN or CUDA_WRAP_SRCS:"
I wanted to launch the process from firebreath,so I included "boost/process.hpp". Just including this header alone throws compile error.
could some one help?
FireBreath 1.6.1, FireBreath 1.7.0,windows 8
Error:
2>C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/process/detail/pipe.hpp(129): error C2665: 'boost::system::system_error::system_error' : none of the 7 overloads could convert all the argument types
2> C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/system/system_error.hpp(39): could be 'boost::system::system_error::system_error(int,const boost::system::error_category &,const std::string &)'
2> C:\Projects\plugin\FireBreath\src\3rdParty\boost\boost/system/system_error.hpp(43): or 'boost::system::system_error::system_error(int,const boost::system::error_category &,const char *)'
2> while trying to match the argument list '(DWORD, overloaded-function, const char [54])'
I faced same problem
boost: 1.47
OS: Windows XP (32 bit VM)
But not with FireBreath
I changed boost::system::system_category to boost::system::system_category() in pipe.hpp line 129
the boost::process library that was in FireBreath has compilation errors in them. I have fixed those errors and it now compiles for me, at least when including . I haven't actually tried to use it on windows yet, nor I suspect has anyone else.
Good luck, hope that helps.
I tried messing around with Win32 binaries lately (this is for a big project of mine).
So after some weeks of research, I now have a solid understanding of how Assembly works, how it is converted into binary code and how x86/x64 opcodes work.
The last piece to the puzzle is figuring out how to properly call Win32 API methods.
I actually asked a question on here in relation to this, and the answer I got was, I should try and compile an Assembly or C program that does this. So I went ahead and tried this in Assembly (I'm using FASM by the way):
format PE console
entry start
section '.idata' import data readable writable
include 'win32a.inc'
library kernel,'kernel32.dll'
import kernel,\
GetStdHandle,'GetStdHandle',\
WriteConsoleA,'WriteConsoleA'
section '.data' data readable writable
string db 'Hello!', 0h
output dd ?
section '.code' code readable executable
start: push -11
call GetStdHandle
pushd 0
pushd output
pushd 7
pushd string
pushd eax
call WriteConsoleA
This is one of the many versions of this code actually. The main problem is, when I call methods like "ExitProcess", generally other functions from the kernel32.dll library, things seem to work out. It's the IO functions that bug me...
I don't understand what's wrong with this code, I don't get any compile-time errors, though when I run it, it just crashes.
So my next idea was, since this didn't work, to try the same in C.
I'm using Cygwin as a compiler and linker...
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MessageBox(NULL, "Hello, world!", "Test", MB_OK);
return 0;
}
This code yielded the same result, the application crashed.
Now, I am not looking for any C/C++ code. My original question of interest was to know how calling extern library function looks like in x86/x64 binary (assembled) code. But I would be very thankful for any resources regarding this topic.
Thank you in advance.
-Tom S.
Your problem is that you need to call ExitProcess at the end to properly end the process. Since you are not doing that, the code currently will continue executing and eventually segfaults because it attempts to execute junk bytes.
In gcc, the close function is used to close the file pointer. However my nvcc complier will not allow that. I can't seem to find a cuda-specific call or alias.
Is there a special cuda file pointer close?
This is the error I get.
error: identifier "close" is undefined
For this simple code;
FILE* fp = fopen(filename,"r");
if(fp == NULL)
{
return NULL;
}
close(fp);
When NVCC compiles your .cu file, it delegates the compilation of the C/C++ parts of the file to your native C/C++ compiler (gcc in your case). So, the error is coming from gcc.
You need to check why gcc is producing this error for the code in this file. Most probably, you have not included the necessary header file where close() is defined, unistd.h. Or try fclose() as another commenter has suggested.