The development environment of this article is: uclinux-2.6 (has been transplanted to the vdsp), vdsp 5.0 this article for the above "Debug dxe file in uClinux" Supplement, the examples used for the above example.
1. CRT ProblemsBecause the program eventually needs to run in uClinux, this is very different from the independent running dxe program, so some initialization work must be done before the program starts to run, this is the task of CRT code. Applications in uClinux usually start with uclibc/libc/sysdeps/Linux/bfin/crt1.s. The code in this file can be used in dxe after slight modification: /* When we enter this piece of code, the user stack looks like this: * argc argument counter (integer) * argv [0] program name (pointer) * argv [1... n] program ARGs (pointers) * null * env [0... n] environment variables (pointers) * null * When we are done here, we want * R0 = argc * R1 = * argv [0] * r2 = * envp [0] */. text. align 2. global _ Start ;. type _ start, stt_func ;. global ___ uclibc_main ;. type ___ uclibc_main, stt_func;/* stick in a dummy reference to main (), so that if an application * is linking when the main () function is in a static library (. a) * We can be sure that main () actually gets linked in */. type _ main, stt_func; _ start:/* clear the frame pointer and the L registers. */FP = 0; L0 = 0; L1 = 0; L2 = 0; l3 = 0;/* l Oad register r1 (argc) from the stack to its final resting place */P0 = sp; R1 = [P0 ++]; /* Copy argv pointer into R2 -- which its final resting place */r2 = P0; SP + =-28; R7 = 0;/* pass highest Stack pointer to the app. */[SP + 24] = P2;/* store the pointer to lD. so's fini that we got in P1. */[SP + 20] = R7;/* OK, now run uclibc's main () -- shouldn't return */R3 = 0; [SP + 12] = R3; [SP + 16] = R3; r0.h = _ main; r0.l = _ main; jump. l ___ uclibc_main; _ start. end: Jump to uclibc_main at the end of this CRT Code. Its declaration is as follows: void _ uclibc_main (INT (* main) (INT, char **, char **), int argc, char ** argv, void (* app_init) (void), void (* app_fini) (void), void (* rtld_fini) (void), void * stack_end) {} you only need to initialize the function and then call the main () function. If you want to correctly use the vdsp library, you also need to call the initialization functions _ mc_data_initialise () and init_devtab.
2 LDF file ProblemsKeywords must be used to generate a dxe file for conversion:
DynamicAt this time, vdsp does not replace the symbol table in the program with the actual value, but records the position to be replaced, this replacement should be performed after the executable file is actually loaded in uClinux. After compilation, you can see a section of. Rela. Text in the dxe file. This section records the replacement table. Note that the dxe file generated at this time cannot be loaded in vdsp, because the vaddr and paddr values in all sections are 0! When you need to use the debugging information in this dxe file, you must set the address definitions in the LDF file to be the same as the addresses allocated by uClinux, and then use the Keyword:
ProcessorIn this case, vdsp replaces the address in the Code with the actual address and generates a dxe file that can be loaded in vdsp. Note that it is only loaded but cannot run normally. Check that the Section. Rela. Text is no longer available in the dxe file. In fact, at the beginning, you can also specify the specific address and use the processor keyword. It can also be converted to a FLT file using elf2flt, it is only because the space is dynamically allocated when the executable files are loaded in uClinux, and the address is always variable, resulting in operation failure. Of course, if we can ensure that the loading order of this program in uClinux is fixed (after init is completed), this method is not a problem.
3. dxe file ProblemsThe dxe file is mainly focused on the section. Rela. Text. We know that there is no symbolic table in the flat file (. symtab), so you must write the symbol values in the symbol table into the code before conversion, that is, replace them with a relative address, during uClinux program loading, replace it with an absolute address. However, this step is not replaced in the dxe file generated by vdsp. This step is not completed when elf2flt conversion is used. Another problem with the dxe file is the offset in. Rela. Text. For uClinux, this offset should point to the byte to be replaced. For vdsp, this offset points to this command. That is to say, they will be 2 bytes different. For example: ++ g_itimescalled; the Assembly Code of this line of statements is: i1.l = 0; i1.h = 0; r2 = [I1]; r2 + = 1; [I1] = R2; where, the address in the two statements assigned to I1 must be replaced with the absolute address of g_itimescalled at runtime. The binary code of these two statements is 11e1 0000 51e1 0000. For vdsp, the pointer it will replace points to 11e1, while uClinux requires this pointer to point to 0000 when calculating the absolute address. Another problem with the dxe file is that, under the release condition, if dynamic is used in the LDF file instead of processor, it will not generate binary code, it is estimated that eliminate unused symbols is in disorder (unconfirmed )!
4. elf2flt ProblemsThe first problem is the version of the converted Flt. elf2flt generates version 5, while uClinux only recognizes version 2 and 4. The second problem is the starting position of the Code. Generally, the starting position of the FLT file code in uClinux is 0x40, but the starting position of the file code generated by vdsp is 0x44, which may cause an error when calculating the absolute address. The third problem is serious. This is about the format of reloc values. The value of each reloc is a 4-byte 32-bit integer arranged by big-Endian. 31 ~ 30 The two data bits indicate the data segment to be replaced:
#define FLAT_RELOC_TYPE_TEXT 0
#define FLAT_RELOC_TYPE_DATA 1
#define FLAT_RELOC_TYPE_BSS 2
29 indicates the relative address or absolute address. 28 ~ 26 indicate the data type to be replaced: # define flat_bfin_reloc_type_16_bit 0 # define flat_bfin_reloc_type_16h_bit 1 # define flat_bfin_reloc_type_32_bit 225 ~ 0 indicates the relative address of the Code to be replaced. For example, to replace a certain number of data segments, the reloc value may be: 01 0 000 00 0000 0000 0000 0001 0101 this means that the data in the relative address 0x015a of the program should be replaced, and the address is located in the data segment, and its hexadecimal number is 0x4000015a. However, in vdsp, this number becomes the last problem: 00 0000 0000 0000 0001 0101 1010 0 01: When uClinux processes files in flat format, the data segment must be 4 aligned, but elf2flt does not complete this job, it is 2 aligned.
