Please find attached <name>.bz2 file. It contains two folders. Folder "h8_with_vects" contains complete sample application including "vects.c" file. Folder "h8_without_vects" contains same sample application except "vects.c" file. I have removed the vects.c file from this folder. I executed following commands on both the folders, 1. make 2. h8300-elf-readelf -aw blink.out > dmp After comparing readelf dump of both the folders, I observed that for H8 target if "vects.c" file is removed from the project, the LMA and VMA addresses generated are wrong. In the absence of "vects.c" file, the offset of first segment in program header becomes zero. This is unexpected because at zero offset ELF header is present. SH or M16C families show expected behavior. After analysing the binutils source code, I found that if I change ELF_MAXPAGESIZE in "elf32-h8300.c" from '0x1' to '0x80' (as in SH family) the problem is solved. My question is, what is the exact value that should be assigned to ELF_MAXPAGESIZE to make it work?
Created attachment 1899 [details] testcases that demonstrate difference in behavior for h8 target, 1... when vects.c file is included and 2... when vects.c file is excluded
Hi Sushil, > After comparing readelf dump of both the folders, I observed that for > H8 target if "vects.c" file is removed from the project, the LMA and > VMA addresses generated are wrong. In the absence of "vects.c" file, > the offset of first segment in program header becomes zero. This is > unexpected because at zero offset ELF header is present. I am not sure why you think that this is a bug. It is perfectly reasonable to load the ELF headers as part of the image. It does no harm. Just because this behaviour is different from the SH or M16C, it does not make it a bug. > My question is, what is the exact value that should be assigned to > ELF_MAXPAGESIZE to make it work? ELF_MAXPAGESIZE should match the size of the memory pages on the target processor. If you are not using a paged memory system, which I assume is the case with the H8, then it should be set to 1. Cheers Nick
Not a bug. The LMA and VMA addresses are correct, as you can see from objdump -h. You seem to be worried about the PT_LOAD header p_vaddr and p_paddr, although that isn't clear from your report. When vects.o is linked at zero, of course the ELF file header and ELF program headers cannot occupy the same location, so the linker assumes the headers will not be loaded. When vects.o is not present, your .text section starts at 0x400, so the headers can be loaded as usual. They will occupy addresses immediately before .text. The linker could create two PT_LOAD headers, one for the file header and program headers, and one for your .text section, but that is inefficient. Instead you get one PT_LOAD header for both. You might like to experiment with ld -N or ld -n, which should tell ld that headers are not needed.