search for: secrel32

Hi I use BlockAddress to get the address of BasicBlock , and I use GlobalVariable 's getInitializer() to pass the address of BasicBlock to the global variable of my own program and then I print it out. But , I found that BlockAddress is not always correct. For example, some function's rsp (stack pointer) or other register is maintained by caller, so it would be like:

...cs.uiuc.edu/pipermail/llvmdev/2012-October/054751.html>. I am still seeing this error with clang compiled from master branch (as well as in 3.3 and 3.2). So I compared asm emitted by clang with that created by gcc, and the difference seems to be that for inter-debug-section references gcc uses .secrel32 <label> directive, whereas clang uses .long <label>. After manually replacing .long's with .secrel32's and building executable, gdb seemed to like new debug info a lot more! I am not sure what's the right approach for fixing this. Should .secrel32 be used on all platform...

On Tue, Aug 17, 2010 at 7:09 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On ELF platforms (at least Linux and FreeBSD) and on Windows, both of > the following are labels (i.e., absolute addresses to be relocated by > the linker) as opposed to offsets relative to the relevant section's > start, even though the DWARF standard says they are offsets: > *

On 30 Jun 2010, at 18:40, Devang Patel wrote: > On Wed, Jun 30, 2010 at 1:57 AM, Artur Pietrek <pietreka at gmail.com> > wrote: >> The problem is that you put difference between two labels >> .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list >> and that will be evaluated by assembler to a constant. It has to be >> a label, >> not a

...fix" from my previous message was helpful only for one compilation unit, but was working incorrectly in case when more CUs were linked together. Since the bug I've linked seems to still be unresolved, I'm sending my solution to it. Basically all that needed to be done was to emit .secrel32 instructions in few places instead of sections offsets in label difference form. Here is how I've been building executable for tests (under MinGW console): llc test.bc -filetype=asm -march=x86 -x86-asm-syntax=att -mtriple=i686-pc-mingw32 -disable-fp-elim llc test_main.bc -filetype=asm -marc...

...ffset in the > .debug_line section of the first byte of the line number information > for this compilation > unit DwarfWriter was using a label reference (instead of a section offset) and it was causing a problem because Windows treats section offsets differently, by emitting the ".secrel32" directive. -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: dwarf-fix.patch Type: text/x-diff Size: 4761 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080616/5df6ecbd/attachment.patch>

Hello, Argiris > Any ideas? 1. Make sure, that you don't mix dwarf and stabs debug information. AFAIR, this can really mess the things 2. It can be, that debug information emitted is not correct. This is known open problem. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Recently I found binaries produced with LLVM impossible to debug under Windows. This was probably related to the following bug: http://llvm.org/bugs/show_bug.cgi?id=13636 Asm generated from .ll files revealed that some offsets to debug information were incorrect: they were absolute instead of relative to their sections. Following patch seemed to have repaired the problem, so I'm

On Thu, Jun 6, 2013 at 2:54 PM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > > I am not sure what's the right approach for fixing this. Should > .secrel32 > > be used on all platforms, or just for Windows PE-COFF? Can somebody > > familiar with intricacies of DWARF format on different platforms please > > comment of this? > section-relative offsets should be used on COFF. Well, not everywhere it seems: for references into the...

...section of the first byte of the line number >> information for this compilation >> unit > > DwarfWriter was using a label reference (instead of a section > offset) and it was causing a problem because Windows treats > section offsets differently, by emitting the ".secrel32" directive. > > > -Argiris > > <dwarf-fix.patch>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...rt_xt_start__ = . ; KEEP (*(SORT(.CRT$XT*))) /* Termination */ ___crt_xt_end__ = . ; } /* Windows TLS expects .tls$AAA to be at the start and .tls$ZZZ to be at the end of the .tls section. This is important because _tls_start MUST be at the beginning of the section to enable SECREL32 relocations with TLS data. */ .tls BLOCK(__section_alignment__) : { ___tls_start__ = . ; KEEP (*(.tls$AAA)) KEEP (*(.tls)) KEEP (*(.tls$)) KEEP (*(SORT(.tls$*))) KEEP (*(.tls$ZZZ)) ___tls_end__ = . ; } .endjunk BLOCK(__section_alignment__) : { /* end...

...*(SORT(.CRT$XT*))) /* Termination */ > ___crt_xt_end__ = . ; > } > /* Windows TLS expects .tls$AAA to be at the start and .tls$ZZZ to be > at the end of the .tls section. This is important because _tls_start > MUST > be at the beginning of the section to enable SECREL32 relocations > with TLS > data. */ > .tls BLOCK(__section_alignment__) : > { > ___tls_start__ = . ; > KEEP (*(.tls$AAA)) > KEEP (*(.tls)) > KEEP (*(.tls$)) > KEEP (*(SORT(.tls$*))) > KEEP (*(.tls$ZZZ)) > ___tls_end__ = . ; >...

COFF lld doesn't support the linker script at the moment, and I'm sad to say that it is very unlikely to support that in the future. Linker script support is so huge that I can't imagine we really want it for COFF. GNU BFD linker supports it because the linker is built as an interpreter for the built-in linker script (and that's one of the reasons why GNU linker is by far more

Hello, I have a user who is trying to get LLD to link for the cygwin target: https://github.com/zig-lang/zig/issues/751 Currently the issue they are running into is needing to define a linker script, but the COFF driver (or MinGW driver) does not have support for that. Is there documentation or advice for how to use LLD to link for cygwin? As a starting point, which driver to use? Regards,