search for: pt_loads

hpa wrote: > On July 7, 2019 8:37:10 AM PDT, Sebastian Herbszt <herbszt at gmx.de> > wrote: > >Gene, > > > >it looks like the syslinux master branch is broken since February > >[1]. Peter created the wip.makefixes branch but I wasn't able to get > >it working (yet) and it lacks activity since March. > > > >I think it might be time to revert

More recent versions of the GNU linker (>= 2.31) create a separate code "PT_LOAD" segment by default (as of https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f6aec96dce1ddbd8961a3aa8a2925db2021719bb). Building syslinux EFI images with this -zseparate-code enabled creates broken EFI images, since efi/wrapper.c only copies the first PT_LOAD segment to the EFI. This patch adds

I wonder what is correct way to create PT_LOADs when linkerscript is used ? Currently we create new one for each section that changes access flags. But ld seems to do different thing. Imagine we have next sections: .section .AX.1,"ax" .quad 1 .section .A.1,"a" .quad 2 .section .AW.1,"aw" .quad 3 And script: SECTIO...

Hi I’m having a trouble linking a special program with lld and the above error is generated. I narrowed it down to lld/Writer.cpp:getFileAlignment (). (Well, my local repository is from a while back (version 10) and for me it is lld/Writer.cpp:computeFileOffset ()) Either way, where it is calculating the file offset when two sections share same PT_LOAD, the formula used is off2 = off1 + (VA2 –

This patch updates x86_64 linker script to pack any .note.* sections into a PT_NOTE segment in the output file. To do this, we tell ld that we need a PT_NOTE segment. This requires us to start explicitly mapping sections to segments, so we also need to explicitly create PT_LOAD segments for text and data, and map the sections to them appropriately. Fortunately, each section will default to its

My target requires that text section be at 0x0 so "-Ttext 0x0" is passed to the linker. When I link with gold, it goes through; but lld fails. Instead of always returning the same calculation, when I change the calculation to the following, it links: return first->offset + (os->addr > first->addr ? os->addr - first->addr :

On 2020-08-13, David Blaikie via llvm-dev wrote: >Sounds like the llvm-objcopy source code (llvm/tools/llvm-objcopy) is >probably a good place to start. > >On Thu, Aug 13, 2020 at 8:11 AM Joseph via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> >> Hey, >> >> LLVM has logic to parse ELF and PE binaries using `llvm::object::createBinary`. I tried to

>>That boot_params.hdr.code32_start field is probably either invalid (bad reloc or something else causing the bootloader to >>calculate the wrong address) or valid but the thing it thinks it is pointing to wasn't loaded (missing PT_LOAD etc.). >boot_params.hdr.code32_start field is valid :) It is 0x100000, like expected > >Then I suspect that that segment isn't being

>That address seems to come from >here: https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/arch/x86/boot/pm.c#L124 > >``` >protected_mode_jump(boot_params.hdr.code32_start, > (u32)&boot_params + (ds() << 4)); >``` > >That boot_params.hdr.code32_start field is probably either invalid (bad reloc or something else causing the

I can't send the exact objects, but I'll try to reproduce. Thanks A On 11/16/20, 9:48 AM, "Fāng-ruì Sòng" <maskray at google.com> wrote: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, Nov 16, 2020 at 9:05 AM Moshtaghi, Alireza

Gene, it looks like the syslinux master branch is broken since February [1]. Peter created the wip.makefixes branch but I wasn't able to get it working (yet) and it lacks activity since March. I think it might be time to revert commit 458a54133ecd ("Fix all warnings, and better separate code that should not be mixed") which broke master. Then apply at least the outstanding patch

This is a common pitfall: people think that .text is the first section of the traditional concept "text segment" (which does not apply with LLD layout and GNU ld's -z separate-code layout) You need to use --image-base=0 https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html#breaking-changes On Mon, Nov 16, 2020 at 10:31 AM Moshtaghi, Alireza <Alireza.Moshtaghi at

On Tue, Jul 23, 2019 at 1:30 PM Sebastian Herbszt <herbszt at gmx.de> wrote: > > hpa wrote: > > On July 7, 2019 8:37:10 AM PDT, Sebastian Herbszt <herbszt at gmx.de> > > wrote: > > >Gene, > > > > > >it looks like the syslinux master branch is broken since February > > >[1]. Peter created the wip.makefixes branch but I wasn't

Hi Alireza, getFileAlignment was renamed in Oct 2018. It seems that you may have sectionA and sectionB in one PT_LOAD while sectionB has a lower address. This is invalid. Can you provide more information about how you have a sectionB with a lower address? Note that LLD has an error "unable to move location counter backward for: ". On Sun, Nov 15, 2020 at 12:20 AM Moshtaghi, Alireza via

On Mon, Nov 16, 2020 at 9:05 AM Moshtaghi, Alireza <Alireza.Moshtaghi at netapp.com> wrote: > > My target requires that text section be at 0x0 so "-Ttext 0x0" is passed to the linker. > When I link with gold, it goes through; but lld fails. > Instead of always returning the same calculation, when I change the calculation to the following, it links: > return

When linking a project with lld, the android libc links to __executable_start which isn't defined when linking with lld (tried on x86), but is when linking with gnu ld it seems. I tried: .globl __executable_start __executable_start = __ehdr_start as a workaround but seems to be ignored. Anyone know a better workaround? Thanks, -- Carlo Kok RemObjects Software

Hi, On 2018-08-03 00:09, Ady Ady via Syslinux wrote: > I guess you are in Gentoo. > > Even if you are not using Debian, you could: > > 1_ Download the syslinux-related binary packages from the Debian > "experimental" (_not_ to be confused with "unstable") repository > (currently, "6.04~git20171011.af7e95c3+dfsg1-3") and take: > > * from

Hey, LLVM has logic to parse ELF and PE binaries using `llvm::object::createBinary`. I tried to search in the codebase to see if there's a possibility to add/remove sections after parsing a binary and re-write the binary to another location. Basically, like what llvm-objcopy does. Can you point me to the right classes to look into, if this is something that LLVM has? Many thanks Joseph

Actually it is the combination of -Ttext 0x0 and --no-rosegment that cause the problem. You can reproduce using any c file using following: clang test.c -fuse-ld=lld -Wl,-Ttext,0x0 -Wl,--no-rosegment A On 11/16/20, 9:52 AM, "llvm-dev on behalf of Moshtaghi, Alireza via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: NetApp

PE headers code_sz and image_sz indicate more or less, the size of the file and the size of the in-memory image. They are now given the right value. In the ELF format, only the program headers are reliable to determine the actually needed part of the file and the in-memory size. The .bss section should always be marked as NOLOAD for ld since its content shouldn't be included into the binary