similar to: [LLVMdev] .debug_frame not produced by default?

Commit-ID: 048bfb0df170d4a43142adcee8a2dffdfc2c1e9f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=048bfb0df170d4a43142adcee8a2dffdfc2c1e9f Author: James Cowgill <james.cowgill at mips.com> AuthorDate: Fri, 2 Mar 2018 08:33:01 -0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Wed, 2 Jan 2019 03:08:04 +0000 [klibc] mips: use -Ttext-segment

We need to build with -mno-pic to disable all uses of GP, as well as use a custom linker script to avoid collisions between klibc.so's and the executable's segments. Signed-off-by: James Clarke <jrtc27 at jrtc27.com> --- usr/klibc/arch/ia64/MCONFIG | 3 + usr/klibc/arch/ia64/crt0.S | 4 - usr/klibc/arch/ia64/klibc.ld | 267 ++++++++++++++++++++++++++++++++++++++++++

Commit-ID: 8418552770110e9864ab24d60d8481fac58d3a65 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=8418552770110e9864ab24d60d8481fac58d3a65 Author: James Clarke <jrtc27 at jrtc27.com> AuthorDate: Mon, 21 Jan 2019 21:26:57 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Mon, 21 Jan 2019 22:51:27 +0000 [klibc] ia64: Fix shared build We

On Thu, Mar 20, 2014 at 10:41 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote: >> While comparing debug info between GCC and Clang I found a section >> that only Clang produces and GCC never produces: debug_frame. >> >> It seems (though I haven't verified this with absolute

I'm cross compiling using clang for x86_64 windows using SEH exceptions. If at all possible, I would like to enable unwind tables to be generated in debug_frame, but I was unable to figure out how to accomplish this. Is there a supported way? Thanks, Keno

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

The parts of klibc specific to the mips architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 8dc79563c06020d8844b9e9b821741828039b59e tree b957c8fb1fddf486f5c26b1880726051d4f6aaad parent bc9b363b31d301ab94c115cccc2e079c0d318498 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:31 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

From: Dejan Latinovic <Dejan.Latinovic at imgtec.com> --- usr/include/arch/mips64/klibc/archconfig.h | 3 + usr/include/arch/mips64/klibc/archsetjmp.h | 39 ++++++ usr/include/arch/mips64/machine/asm.h | 76 ++++++++++ usr/include/fcntl.h | 2 +- usr/include/sys/md.h | 1 + usr/include/sys/resource.h | 4 +-

From: Sylvain Gault <sylvain.gault at gmail.com> Some linker scripts were splitted into i386 and x86_64 versions in commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were left there. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- core/syslinux.ld | 414 ------------------------------------------------ core/x86_64/syslinux.ld | 389

Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:

Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Adapt module loading to support PIE relocations. Generate dynamic GOT if a symbol requires it but no entry exist in the kernel GOT. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/Makefile | 4 + arch/x86/include/asm/module.h

Hi, We are trying to use LLVM API to programmatically obtain a list of relocations in an ELF file. The way we are doing this is exactly as llvm-objdump does it: we are iterating through sections and in each section we are iterating over relocations (see PrintRelocations() function at https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp). However, it does not give us

On Feb 11, 2013, at 18:13, Eli Bendersky <eliben at google.com> wrote: > On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: >> Hi, >> >> I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory

On 11/4/2013 1:40 PM, Jack Carter wrote: > On 11/04/2013 11:15 AM, Eric Christopher wrote: >> >> >> >> On Mon, Nov 4, 2013 at 11:05 AM, Shankar Easwaran >> <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote: >> >> Hi, >> >> I was looking at the ARM ABI >>

Sri and I have been working on this over the past few months, and we've made some good progress that we'd like to share and get feedback on. Our work is based on the 'experimental-relr' prototype from Cary that is available at 'users/ccoutant/experimental-relr' branch in the binutils repository [1], and was described earlier in this thread:

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

Hi, I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish

On Mon, Dec 11, 2017 at 6:14 PM, Roland McGrath <roland at hack.frob.com> wrote: > > On Mon, Dec 11, 2017 at 3:50 PM Rahul Chaudhry via gnu-gabi <gnu-gabi at sourceware.org> wrote: >> >> A simple combination of delta-encoding and run_length-encoding is one of the >> first schemes we experimented with (32-bit entries with 24-bit 'delta' and an >>