search for: sh_offset

This adds [f]getc() and fgets() for parsing config files. Probably hard to avoid. Still trying to decide if I actually want to add system() or not. -hpa

...in that case, e.g. with respect to -Ox and > -gx, so it's perhaps a bit apples to oranges. > > When building with gcc 6.2.1 and linking with lld trunk, I get a link error: > > bin-lld/ld: error: lib/libse.a(file1.cpp.o): unaligned data That means that file1.cpp.o has an invalid sh_offset. Can you post a readelf -SW of it? How is it being created? The error is from ELF.h: ELFFile<ELFT>::getSectionContentsAsArray. Cheers, Rafael

...(memcmp(hdr->e_ident, ELFMAG, 4) !=3D 0 || + !elf_check_arch(hdr) || + hdr->e_type !=3D ET_DYN) + panic("Bogus ELF in vsyscall DSO\n"); + + hdr->e_entry +=3D VDSO_HIGH_BASE; + sechdrs =3D (void *)hdr + hdr->e_shoff; + secstrings =3D (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset; + + for (i =3D 1; i < hdr->e_shnum; i++) { + if (!(sechdrs[i].sh_flags & SHF_ALLOC)) + continue; + + sechdrs[i].sh_addr +=3D VDSO_HIGH_BASE; + if (strcmp(secstrings+sechdrs[i].sh_name, ".dynsym") =3D=3D 0) { + Elf32_Sym *sym =3D (void *)hdr + sechdrs[i].sh_offset; +...

...(memcmp(hdr->e_ident, ELFMAG, 4) !=3D 0 || + !elf_check_arch(hdr) || + hdr->e_type !=3D ET_DYN) + panic("Bogus ELF in vsyscall DSO\n"); + + hdr->e_entry +=3D VDSO_HIGH_BASE; + sechdrs =3D (void *)hdr + hdr->e_shoff; + secstrings =3D (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset; + + for (i =3D 1; i < hdr->e_shnum; i++) { + if (!(sechdrs[i].sh_flags & SHF_ALLOC)) + continue; + + sechdrs[i].sh_addr +=3D VDSO_HIGH_BASE; + if (strcmp(secstrings+sechdrs[i].sh_name, ".dynsym") =3D=3D 0) { + Elf32_Sym *sym =3D (void *)hdr + sechdrs[i].sh_offset; +...

Martin Richtarsky <s at martinien.de> writes: > Output looks as follows [1] Seems sh_offset is missing? That is what readelf prints as Off > [17] .rela.text RELA 0000000000000000 071423 001728 18 > 1 4 8 The offset of rela text should have been aligned, but it is not. Can you report a bug on icc? As a work around using the gnu assembler if possible sho...

...; - - /* First find the strtab section */ - fseek(f_in, shstrndx * shentsize, SEEK_CUR); - fread(&shdr, sizeof(shdr), 1, f_in); - strtab = malloc(shdr.sh_size); - if (!strtab) { - fprintf(stderr, "Failed to malloc strtab\n"); - exit(EXIT_FAILURE); - } - - fseek(f_in, shdr.sh_offset, SEEK_SET); - fread(strtab, shdr.sh_size, 1, f_in); - - /* Now search for the .bss section */ - fseek(f_in, shoff, SEEK_SET); - for (i = 0; i < shnum; i++) { - rv = fread(&shdr, sizeof(shdr), 1, f_in); - if (!rv) { - fprintf(stderr, "Failed to read section table\n"); -...

...; - - /* First find the strtab section */ - fseek(f_in, shstrndx * shentsize, SEEK_CUR); - fread(&shdr, sizeof(shdr), 1, f_in); - strtab = malloc(shdr.sh_size); - if (!strtab) { - fprintf(stderr, "Failed to malloc strtab\n"); - exit(EXIT_FAILURE); - } - - fseek(f_in, shdr.sh_offset, SEEK_SET); - fread(strtab, shdr.sh_size, 1, f_in); - - /* Now search for the .bss section */ - fseek(f_in, shoff, SEEK_SET); - for (i = 0; i < shnum; i++) { - rv = fread(&shdr, sizeof(shdr), 1, f_in); - if (!rv) { - fprintf(stderr, "Failed to read section table\n"); -...

...eh64->e_entry; /* Can be overridden further down... */ @@ -378,7 +378,7 @@ struct multiboot_header *map_image(void *ptr, size_t len) continue; /* SHF_ALLOC sections should have PHDRs */ align = sh64[i].sh_addralign ? sh64[i].sh_addralign : 0; - addr = map_data((char *)ptr + sh64[i].sh_offset, + addr = map_data((char *)ptr + sh64[i].sh_offset, sh64[i].sh_size, align, MAP_HIGH); if (!addr) { error("Failed to map symbol section\n"); -- 2.0.0

...dress: The PT_LOAD fixes are doable. + adding a section within the existing address ranges: this is very difficult due to many implicit inter-section references. If you have an advanced binary rewriting tool, this is still doable, but definitely brittle. File offsets (p_offset,sh_offset) can be reconstructed from addresses. llvm-objcopy/ELF/Object.cpp layoutSections has some code. A more sophisticated implementation is in the linker: lld/ELF/Writer.cpp assignFileOffsets

...================ --- include/llvm/Object/ELF.h (revision 172846) +++ include/llvm/Object/ELF.h (working copy) @@ -1000,7 +1000,7 @@ switch (symb->getType()) { case ELF::STT_SECTION: - Result = Section ? Section->sh_addr : UnknownAddressOrSize; + Result = Section ? Section->sh_offset : UnknownAddressOrSize; return object_error::success; case ELF::STT_FUNC: case ELF::STT_OBJECT: -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130118/506f6f0a/attachment.html> ----------...

..._shnum; i++) { + addr_t align; + + if (!sh64[i].sh_size) + continue; /* Empty section */ + if (sh64[i].sh_flags & SHF_ALLOC) + continue; /* SHF_ALLOC sections should have PHDRs */ + + align = sh64[i].sh_addralign ? sh64[i].sh_addralign : 0; + addr = map_data((char *)ptr + sh64[i].sh_offset, + sh64[i].sh_size, align, MAP_HIGH); + if (!addr) { + error("Failed to map symbol section\n"); + return NULL; + } + sh64[i].sh_addr = addr; } } } else if (mbh_len && (mbh->flags & MULTIBOOT_AOUT_KLUDGE)) { diff U3 syslinux-6.03/com32/mboot/mb...

...set > Again, referring to the definition of the "st_value" field above, the file offset of the symbol is the section offset plus the symbol's offset in the section, which is reflected in the new code: > >    Result = symb->st_value + >             (Section ? Section->sh_offset : 0); > > The old code subtracted Section->sh_addr from that for reasons that are not entirely clear to me. > > I'm not sure where this creates a problem for you? AFAICS, neither llvm-objdump nor llvm-nm use the symbol's file offset. It's also not clear from your pastes o...

The PE headers of the generated efi file were quite buggy. And since OVMF perform a few consistency checks, syslinux was unable to run on it. I don't pretend to have a thorough understanding of the PE+ headers, some bugs may remain. :) Celelibi (4): efi: Fix PE header field rva_and_sizes_nr efi: Location, size and alignment of .text section efi: Useless relocations in PE file efi: PE

...(hdr->e_ident, ELFMAG, 4) !=3D 0 || + !elf_check_arch(hdr) || + hdr->e_type !=3D ET_DYN) + panic("Bogus ELF in vsyscall DSO\n"); + + hdr->e_entry +=3D VSYSCALL_RELOCATION; + + sechdrs =3D (void *)hdr + hdr->e_shoff; + secstrings =3D (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset; + + for (i =3D 1; i < hdr->e_shnum; i++) { + if (!(sechdrs[i].sh_flags & SHF_ALLOC)) + continue; + + sechdrs[i].sh_addr +=3D VSYSCALL_RELOCATION; + if (strcmp(secstrings+sechdrs[i].sh_name, ".dynsym") =3D=3D 0) { + Elf32_Sym *sym =3D (void *)hdr + sechdrs[i].sh_offset;...

...(hdr->e_ident, ELFMAG, 4) !=3D 0 || + !elf_check_arch(hdr) || + hdr->e_type !=3D ET_DYN) + panic("Bogus ELF in vsyscall DSO\n"); + + hdr->e_entry +=3D VSYSCALL_RELOCATION; + + sechdrs =3D (void *)hdr + hdr->e_shoff; + secstrings =3D (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset; + + for (i =3D 1; i < hdr->e_shnum; i++) { + if (!(sechdrs[i].sh_flags & SHF_ALLOC)) + continue; + + sechdrs[i].sh_addr +=3D VSYSCALL_RELOCATION; + if (strcmp(secstrings+sechdrs[i].sh_name, ".dynsym") =3D=3D 0) { + Elf32_Sym *sym =3D (void *)hdr + sechdrs[i].sh_offset;...

Rui Ueyama <ruiu at google.com> writes: > On Tue, Dec 5, 2017 at 1:22 PM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Martin Richtarsky <s at martinien.de> writes: >> >> > Output looks as follows [1] Seems sh_offset is missing? >> >> That is what readelf prints as Off >> >> > [17] .rela.text RELA 0000000000000000 071423 001728 >> 18 >> > 1 4 8 >> >> The offset of rela text should have been aligned, but it is not. Can you >>...

...? (2) Symbol offset Again, referring to the definition of the "st_value" field above, the file offset of the symbol is the section offset plus the symbol's offset in the section, which is reflected in the new code: Result = symb->st_value + (Section ? Section->sh_offset : 0); The old code subtracted Section->sh_addr from that for reasons that are not entirely clear to me. I'm not sure where this creates a problem for you? AFAICS, neither llvm-objdump nor llvm-nm use the symbol's file offset. It's also not clear from your pastes of llvm-objdump and...

...r_err("%s: module GOT section missing\n", mod->name); + return -ENOEXEC; + } + if (!syms) { + pr_err("%s: module symtab section missing\n", mod->name); + return -ENOEXEC; + } + + for (i = 0; i < ehdr->e_shnum; i++) { + Elf64_Rela *rels = (void *)ehdr + sechdrs[i].sh_offset; + int numrels = sechdrs[i].sh_size / sizeof(Elf64_Rela); + + if (sechdrs[i].sh_type != SHT_RELA) + continue; + + /* sort by type, symbol index and addend */ + sort(rels, numrels, sizeof(Elf64_Rela), cmp_rela, NULL); + + gots += count_gots(syms, rels, numrels); + } + + mod->arch.core.got-...

Hi all, I'm using the MC framework for a project, and while updating to latest trunk (r148672) encountered the following issue: It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have been changed to add the symbol's offset to the offset of the containing section? This has the following implications: To get the /actual/ fileoffset, I now need to do: Symbol.getFileOffset()

Martin Richtarsky <s at martinien.de> writes: > Rafael Avila de Espindola wrote : >>> Maybe gdb needs to fall back to slower line number resolution because >>> e.g. >>> low and high bounds cannot be retrieved and debug_line_address is 0? >> >> It is hard to know without a reproducible. I tried gdb on clang itself >> build with both clang and