Where I can find the piece of code responsible to generate MLO file?
In u-boot source code if I want to find the place belongs to creation of MLO file where I can findout the place.
The code related to making MLO is found in tools/omapimage.c and tools/omapimage.h.
Related
Background:
I am generating a JIT code (which generates x86-64 code). After the end of JIT process, I have a .text section, a .data section and a .eh_frame section generated (.eh_frame is used for stack unwinding). I am able to execute this JIT code successfully. But the issue is GDB. I want to be able to debug this JIT code using GDB (specifically the 'backtrace' command of GDB should work).
Problem:
I need to tell GDB about this loaded JIT code (in particular I need to tell GDB about .eh_frame so it can use that frame for stack-unwinding). I see that GDB has a JIT interface: https://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html
Possible Solutions:
There are two options here:
Hand over a ELF file to GDB
Write a Customer Jit-Reader plugin to handle debugging of custom object file.
Right now I have a custom object file (just bunch of three independent sections loaded into memory). I don't want to write my own Jit Reader plugin.
Blocking Issue:
Does anyone knows existing code that will help me package these three independent sections into a simple ELF file (which I can then register with GDB by calling __jit_debug_register_code())? I am guessing all I need to do is write some header (conforming to ELF specifications) which have names and pointers to the section. Is there existing open source code for this or if not, can someone point me towards how to do this packaging myself?
I need bare minimum ELF file so that GDB is happy (I don't need to Load the ELF file as .text and .data section are already loaded)
libelf could be of help for constructing an ELF object. There are open-source implementations available at:
elftoolchain (BSD licensed)
elfutils (GPL).
I wanna know where the parsing of device tree will happen in linux kernel? I mean where can i find the kernel source code to parse all device tree info, all nodes?
TIA.
You can find the parser code here, CONFIG_LIBFDT is config which builds it so look for the Makefile in lib directory, which builds libfdt_files.
I need to add a custom segment to standard ELF file. Even I find some manual, I cannot do it. Could anyone give some help? Thanks.
I have a FreeRTOS code under KEIL compiler and all is OK. When I convert the same code to CooCox under GCC, where are only changes in asm code in port.c etc. It does not work. It is looping in debug in function xPortStartScheduler() where prvPortStartFirstTask() go to Svc_Handler and again to xPortStartScheduler() etc. I think that problem can be somewhere in vectors or startup file.
In CooCox I can't find heap and stack initialization instead of Keil sturtup.
Someone has an idea?
Problem was solved by rewriting vector table of imported CooCox sturtup where "vPortSVCHandler" was not defined. – Hw-dev Cz
I'm new to freeRTOS but you may find the startup file in CooCox by adding CMSIS boot component to the project. View->Repository and add CMSIS boot component to visualize the startup file in cmsis_boot/startup directory.
In our project, we are building an ELF file and a partially linked file (PLF) which is converted to a proprietary format and loaded into memory after the ELF is loaded. We use Codewarrior to run and debug, which has been working just fine (the C++ source code is always available to step through when debugging).
I've recently made a change where some code and data are compiled into a different section in the PLF file (.init, which was previously empty). Now, when debugging, a majority of the files are available only in assembler. When I re-build, no longer using .init, we can step through C++ source code again.
Does anyone know why this would be the case?
why this would be the case
One reason could be that codewarrior is not expecting to find code in .init section.
You are unlikely to get a good answer here. Try codewarrior support forums.
I got this working by switching the order of the sections using the linker command file (.lcf) so that the .init section comes second after .text. I guess as Employed Russian suggests, CodeWarrior is surprised by having code in .init and craps out. Changing the order of the sections seems to have no ill effects and now debugging works as expected again.