similar to: lld/coff section name .debug_str is longer than 8 characters

Indeed, it's 32bits x86 and there's no .safeseh or anything like it, even readobj -coff-load-config says nothing: File: ConsoleApplication830.exe Format: COFF-i386 Arch: i386 AddressSize: 32bit Now I know what to look for, thanks! On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote: > This is 32-bit x86, right? Sounds like the exception handler did not > appear in the /safeseh

On 23/10/12 01:30, Michael Spencer wrote: > On Mon, Oct 22, 2012 at 7:53 AM, r4start <r4start at gmail.com> wrote: >> On 20/10/12 03:15, Michael Spencer wrote: >>> On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: >>>> Hi all. >>>> >>>> While compiling next code >>>> @A = weak unnamed_addr constant {

On Wed, Oct 31, 2012 at 9:41 AM, r4start <r4start at gmail.com> wrote: > On 24/10/12 17:03, r4start wrote: >> >> On 23/10/12 01:30, Michael Spencer wrote: >>> >>> On Mon, Oct 22, 2012 at 7:53 AM, r4start <r4start at gmail.com> wrote: >>>> >>>> On 20/10/12 03:15, Michael Spencer wrote: >>>>> >>>>> On

I have @_rtti_a_a = linkonce_odr constant in two files that end up as coff object files. Shoudln't the linkonce_odr prevent duplicate symbol: __rtti_a_a \consoleapplication149.o and __rtti_a_a island.lib(island.o) from happening in LLD? If not what alternative can I use? THis is used for template like generics, so having duplicate functions and globals is going to happen a lot) (Side

On Mon, Oct 22, 2012 at 7:53 AM, r4start <r4start at gmail.com> wrote: > On 20/10/12 03:15, Michael Spencer wrote: >> >> On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: >>> >>> Hi all. >>> >>> While compiling next code >>> @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0

On 24/10/12 17:03, r4start wrote: > On 23/10/12 01:30, Michael Spencer wrote: >> On Mon, Oct 22, 2012 at 7:53 AM, r4start <r4start at gmail.com> wrote: >>> On 20/10/12 03:15, Michael Spencer wrote: >>>> On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: >>>>> Hi all. >>>>> >>>>> While

On 03/11/12 01:37, Michael Spencer wrote: > On Wed, Oct 31, 2012 at 9:41 AM, r4start <r4start at gmail.com> wrote: >> On 24/10/12 17:03, r4start wrote: >>> On 23/10/12 01:30, Michael Spencer wrote: >>>> On Mon, Oct 22, 2012 at 7:53 AM, r4start <r4start at gmail.com> wrote: >>>>> On 20/10/12 03:15, Michael Spencer wrote:

Hi, I'm getting: Unhandled exception at 0x00C211F0 in ConsoleApplication830.exe: 0xC00001A5: An invalid exception handler routine has been detected (parameters: 0x00000001). With some fairly simple SEH enabled routine: define i32 @__elements_entry_point_main(%._gt2a_RemObjects_d_Elements_d_System_d_Array_t_1s*) #0 personality i8* bitcast (i32 ()* @_elements_exception_handler to i8*) !dbg

On 20/10/12 03:15, Michael Spencer wrote: > On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: >> Hi all. >> >> While compiling next code >> @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, >> section ".data" >> was discovered that llc ignores weak linkage if we emit it in COFF object. >>

Hello all, Last year I submitted a bug regarding the use of 'parallel_for_each' and Windows Concurrency Library. We have found that when compiling in Visual Studio 2015 and 2017 with /MTd, the use of 'concurrency::parallel_for_each' can cause unhandled exceptions when the program is exiting. https://bugs.llvm.org/show_bug.cgi?id=34976 After having some difficulty clarifying this

Hi, I am using the llvm codegen facility (version 7.0.1) to translate LLVM IR for different platforms. I have this error particularly in win64 platform. In my IR code I have such code snippet: %50 = call i8* @my_function(i8* %48, double 2.000000e+00, double 2.000000e+00) ... declare dllimport i8* @my_function(i8*, double, double) By passing it to llc.exe, I find following symbol is declared in

> > If you want to define an alias symbol "bar" to "foo" (which is an > extension you want to provide), one way is to create an object file that > defines "bar" and "__imp_bar" as aliases to "foo" and "__imp_foo", > respectively, and add that object file to the import library. As a result, > the import library file

Hey Lang and Stefan, Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin… So how is it possible for that to work? However… when I load an COFF object file, am I able to change the relocations to dllimport somehow? I honestly can’t imagine how this would work since the machine code is probably already adjusted to

Hi Reid, Sure. Here I attach the trimmed IR(sim_0.ll) which llc.exe takes and produces a 0 storage class symbol. The IR is fairly long but there is only 1 usage of real constant as actual argument passing to function iki_vlog_time() at line 137. The version of llc.exe is $ llc.exe --version LLVM (http://llvm.org/): LLVM version 7.0.1 DEBUG build. Default target: x86_64-pc-win32 Host

Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations. nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[ 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some

On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: > Hi all. > > While compiling next code > @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, > section ".data" > was discovered that llc ignores weak linkage if we emit it in COFF object. > Attached patch solves this problem, please review. > > I found some

Hi all. While compiling next code @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, section ".data" was discovered that llc ignores weak linkage if we emit it in COFF object. Attached patch solves this problem, please review. I found some similar tests in test/Objects/Inputs. Should I do something like trivial.ll checking or there is a better way to check

Hey guys, Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) Any thoughts on skipping the "DW_" (maybe even the AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM

> On Jan 19, 2015, at 10:26 AM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Hey guys, >> >> Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every