As we all know, GRUB can boot an ELF executable kernel. But here, in source code of GRUB, in which file and/or directory, the source of ELF loader resides? Also which file contains source code of Stage1 and Stage2?
Related
I am trying to build a ROM image using CMake. I have a project root directory CMakeLists.txt file which calls add_subdirectory() to build the different components for the ROM image. These components are output in binary format. Once this is done I wish to combine the resulting binaries into a single image.
Currently I have a final add_subdirectory() call that is meant to use objdump to convert the binary output of the other modules to an object file and then link these into a unified elf that is then converted with objdump.
add_executable(rom_image.bin)
foreach (COMPONENT ${COMPONENTS})
set(COMPONENT_BINARY_FILENAME "${CMAKE_BINARY_DIR}/${COMPONENT}/output.bin")
set(COMPONENT_OBJECT_FILENAME "${COMPONENT}.o")
add_custom_command(
TARGET rom_image.bin
PRE_BUILD
OUTPUT ${COMPONENT_OBJECT_FILENAME}
DEPENDS ${COMPONENT_BINARY_FILENAME}
COMMAND ${OBJCOPY_PROGRAM}
ARGS --input-target=binary --output-target=elf32-littlearm --binary-architecture=arm ${COMPONENT_BINARY_FILENAME} ${COMPONENT_OBJECT_FILENAME}
)
endforeach()
This does not work as CMake complains that the target (rom_image.bin) has no source files.
I have mac os CMake project where I'm trying to bundle a Wavefront text .obj files into the resources of the application (https://en.wikipedia.org/wiki/Wavefront_.obj_file): the content is irrelevant, but just happens that the standard extension for that format is .obj.
Now, If I name the files something.obj_ I get everything working properly, so this is not a "mac question". But I want to keep original extension .obj.
What I want to achieve is that my target executable has also a dependency on the .obj resource file, since a change on the resource should recreate the bundle with the new file.
My problem is that any dependency on a file named .obj gets it interpreted as a code object and the linker just issues the errors:
ld: warning: ignoring file ../../assets/file.obj, file was built for unsupported file format ( 0x23 0x20 0x42 0x6C 0x65 0x6E 0x64 0x65 0x72 0x20 0x76 0x32 0x2E 0x37 0x39 0x20 ) which is not the architecture being linked (x86_64): ../../assets/file.obj
From what I see, any other files that are on the same directory with "unknown" extensions such as .mtl are copied correctly, but this .obj file must be some triggering some rule associated with linker.
How can I get cmake to simply handle the file as a "text file to copy" independently if it was called .obj, .cpp or .o ?
I think I found the solution to my own question:
set_source_files_properties(${ASSET_FILES} PROPERTIES
HEADER_FILE_ONLY ON
)
This will pass ASSET_FILES through the linker without a problem
I am using gcov to test the code coverage in my project. The gcov is giving me output of the test files that i have written using gtest, but it is not giving me the correct output of the actual implementation files. It gives the message "No executable lines". The project is based in QT and C++. Any pointers in this regard will be helpful since I am new to both QT and gtest/gcov.
Some more info:
1. Executed the test binary built using gtest
2. The .o, .gcda and .gcno files are in the same folder
3. I am executing gcov from the location of the source with the -o option to specify the path of the bin files.
This was happening because I had not copied the .gcda files to the directory with the .gcno and .o files. After copying the .gcda files and running the gcov it is running fine. :)
Many resources state that Firmware image is an ELF file/format. I've checked that by executing file command using several firmware images (.bin), the outcome of this command doesn't mention anything related to ELF. Unlike when I executed the same command over ELF files, where I was receiving something like ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, not stripped.
The reason I'm asking about that, I want to test an approach for detecting malicious ELF files, I already have the ELF malicious files, but I don't have benign ELF files, therefore was thinking if I can use Firmware images as benign ELF files.
Most Firmware will be in a binary format, referred to as a bin file.
So these bin files would not be useful for your test.
Here is an answer discussing the difference between the two formats.
https://stackoverflow.com/a/2427229/7275012
Compiler: Mingw GCC compiler
In make file I specified src directory location like below..
dirsrc = ./src
So here I mentioned current directory. The problem is the generated DLL having the Absolute path to the source directory. Is there any way to notify the compiler which should be relative.?
Because I am generating this DLL with Codecoverage information. If I moved my full project structure to somewhere means while simulating the DLL to target, at that time the DLL refers to the absolute path of the source directory.
I need the DLL with relative path to the source directory.? How do I write the make file with relative path to the source directory?
The real problem is,
I am doing code coverage analysis using gcov.
I followed following steps:
1.) I compiled my program with GNU CC options: `-fprofile-arcs -ftest-coverage'.
2.) I got 2 additional file with suffix *.bb and *.bbg in same directory
3.) Running the program will cause profile output to be generated.
For each source file compiled with -fprofile-arcs', an accompanying .da' file will be placed in the source directory. The name of the .da' file is stored as an *_absolute pathname_* in the resulting object file. This path name is derived from the source file name by substituting a .da' suffix.
The problem here is that I am compiling on one machine and running on a seperate machine. Each '.da' file has absoulte pathname in the resulting object file. So it does not find same path on another machine.
Is it possible to have fprofile-arcs and any other profiling-related options in GCC to have file names relative rather than absolute.
please let me asap.! thanks in advance.