similar to: [LLVMdev] misc unused symbols: '_write' and '_abort'

On Wed, 6 Jul 2005, Aaron Gray wrote: > I am working on the MASM backend. > > I do not know what to do about '_write' and '_abort'. They seem to be > added to a modules functions as externals even when they are not being > used. Why is that a problem? > They cannot just be remove just in case they are being used. What are > they there for ? They are part

Hi all, I'm working on a project that uses clang-cl & lld-link to build for Windows, along with some tools out of the Windows SDK... but we're currently pre-building some pieces of MASM assembly code using Microsoft's ml.exe & ml64.exe. Unfortunately, it's not all inline assembly, which clang can already handle, and Microsoft's file-level directives are a bit unusual.

Are you asking what the parsing rules are, or how you should modify the LLVM code to achieve that result? If the latter, you haven’t really given enough detail here. What code, exactly, have you tried modifying? Do you have any ideas for how it could work? -Eli From: Eric Astor <epastor at google.com> Sent: Tuesday, January 21, 2020 2:44 PM To: Eli Friedman <efriedma at

Hi all, Continuing work on llvm-ml (a MASM assembler)... and my latest obstacle is in enabling MASM's convention that (unless specified) all memory location references should be RIP-relative. Without it, we emit the wrong instructions for "call", "jmp", etc., and anything we build fails at the linking stage. My best attempt at this so far is a small patch to

When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR. (e.g. in the MD for DW_TAG_compile_unit's list of subprograms, each of those functions' info is still in the list,

Apologies - I apparently remembered part of the issue incorrectly, so this ended up quite confusing. The problem comes when referencing labels in a different section of the binary. To clarify, if I assemble the code: .data foo BYTE 5 .code mov eax, foo with Microsoft's ml64.exe, it emits an object file disassembling to: 0: 8b 05 00 00 00 00 mov eax, dword ptr [rip]

Agreed, I won't plan to change syntax for anything that hasn't opted in. However... Am I mistaken in thinking clang-cl (for example) is just clang with a different name, which triggers some variant behaviors including parsing cl.exe-style command lines and taking certain flags as implicit? I was hoping to build llvm-ml similarly, by building the features into llvm-mc behind target

On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: > When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR.  (e.g. in the MD for DW_TAG_compile_unit's

On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer wrote: > While trying to hunt down a codegen bug (not yet found) ... Have you considered using bugpoint for your codegen debugging needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > I've collected some small patches you might find useful. Sweet! > Please review and apply as you see fit. I've

On PowerPC we have a failing address sanitizer test when linking with LLD. The issue is that the symbol '__libc_stack_end' is resolved to an undefined weak symbol when linking with LLD but not when linking (with the exact same command/input) with other linkers. Tracing the symbol I see it is resolved to a definition in the dynamic linker as expected:

On Jul 19, 2009, at 8:35 AM, Aaron Gray wrote: > I am getting a simular problem with ___main appearing if '@main' is > used but there is no instance of it in the Module iterators, only in > the relocations. > > Is it possible to do something about these 'ghost symbols' and have > them defined in Module. Rather than having to check for them and > pick

Hi all. I've been lurking here for a couple weeks just trying to get an idea of how to install asterisk. I'm running Debian with a custom kernel version 2.4.18. I think I've got all the dependencies installed - debian packages readline4 and openssl are installed. It's a very barebones install with only the packages relevant to building a kernel and asterisk installed. The

Hola! Para simular matrices de datos normales multivariados con la sentencia rmvnorm (dentro del paquete mvtnorm) se necesita, entre otras cosas, el número de vectores a simular, el vector de parámetros-medias correspondiente a cada variable y su respectiva matriz de Varianza-Covarianza. En este último punto, tengo problemas. En lugar de ingresar una matriz sigma creada por mi, necesito simular

I am getting a simular problem with ___main appearing if '@main' is used but there is no instance of it in the Module iterators, only in the relocations. Is it possible to do something about these 'ghost symbols' and have them defined in Module. Rather than having to check for them and pick them up when processing relocations. Aaron 2009/7/19 Aaron Gray <aaronngray.lists at

2009/7/19 Chris Lattner <clattner at apple.com> > On Jul 18, 2009, at 3:28 PM, Aaron Gray wrote: > > 2009/7/18 Chris Lattner <clattner at apple.com> > >> On Jul 18, 2009, at 2:56 PM, Aaron Gray wrote: >> >> I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc >> >> >> If you're iterating over functions,

I am trying to work through the usage of thinlto for distributed builds. Here is the simple thinlto usage, just add -flto=thin everywhere, easy: clang++ -flto=thin -O3 -c -o CreateWay_.o -DSPEC_CPU -DNDEBUG -DSPEC_CPU_LITTLE_ENDIAN -Wno-dangling-else CreateWay_.cpp clang++ -flto=thin -O3 -c -o Places_.o -DSPEC_CPU -DNDEBUG -DSPEC_CPU_LITTLE_ENDIAN

On Mon, Jul 11, 2016 at 11:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Sean, > > Sean Silva wrote: > > > > But asan won't catch problems (insofar I understand how it works) if > > the free'ed BasicBlock is used as a key in a DenseMap or something -- > > if another BasicBlock gets allocated to the same location

Thanks Teresa Yes it is astar, happen to send a tar of the sources but they are just copies from the spec distribution The ld command is: GNU ld (GNU Binutils) 2.29.1 Thanks for the guidance on path names. The prefix-replace just effects the string written to the object files right? So we could post-process that file with other tools as well, correct? Thanks again --david From: Teresa Johnson

Fails with gold too: Library-native.o:Library.cpp:regway: error: undefined reference to 'vtable for regwayobj' /home/dcallahan/fbsource/fbcode/third-party-buck/platform007/tools/binutils/bin/gold/ld: the vtable symbol may be undefined because the class is missing its key function clang-8: error: linker command failed with exit code 1 (use -v to see invocation) From: Teresa Johnson

Hello, In S-Plus for windows there is a possibility to work with 'scripts' (at least from version 4.5). Is there an equivalent 'function' in R or is there a simular way to work in R Sincerely Fredrik Lundgren -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send