similar to: Help adding entries to .symtab

Hey Paul, first of all thank you for taking the time to answer me, if I understand you correctly, I need to modify the instruction it self so one of it's operands is a symbol, and then at MC layer handle that symbol and add an entry to the symtab for that label? What kind of symbol should I use doing such thing? external symbol or MCSymbol? I was trying to find where in the code during the MC

Hi Liad, I'm not an expert in MC, but what you describe doesn't sound any different from how you would handle a branch instruction. Create an MCSymbol that represents the address of the target instruction; use that symbol as an operand in the referencing instruction; emit the symbol as a label just prior to emitting the target instruction. The second and third steps can occur in either

Hey Tim, thanks for the quick answer, this looks exactly like what I was trying to achieve, I was hoping there was something more clean, I was wondering how the community would accept a change in the TD, if the code at CallinvConvLower.cpp:138 would've passed the IsFixed flag to the AssignFn then all those workarounds wouldn't be needed, this example is only one of a few I can think of for

Hey, I am working on a new back-end, in my back end, I require to pass every argument through a register when calling a function, unless the argument is part of the ellipsis (...) and then pass it through the stack, I've tried creating a CCCustom function to analyze the operands when a function has var args, however, the information whether the out val is fixed or not is not passed into the

Hey all, There seems to be two conventions for git repo directory layout. The official docs suggest the following tree. http://llvm.org/docs/GettingStarted.html#git-mirror llvm (llvm repo) -> tools -> clang (clang repo) -> lld (lld repo) etc. However various llvm-project repos, suggest a different layout: https://github.com/llvm-project/llvm-project-20170507

Hi everyone, I'm faily new to LLVM, I'm working on a new backend. In my backend, one of the requirements is to split a BB on every call, I considered putting some kind of pseudo instruction using the TargetLowering::LowerCall function. Before going said path, I was wondering if there is some way to split the BB before the SelectionDAG is generated, this way the call instruction would be

lld/test/ELF/invalid/symtab-sh-info.s (check-lld-elf) is recently flaky on Windows, e.g. https://reviews.llvm.org/harbormaster/unit/view/192869/ http://45.33.8.238/win/27684/step_10.txt It fails like every 3 or 4 builds. Could someone with a Windows machine check what is going on? Is that due to output non-determinism (just my guess) in yaml2obj.exe? -------------- next part -------------- An

Hi! If there is a string table for section headers, it also gets loaded. Therefore take it into account in size calculation for kernel symtab. Also there is no need to call elf_set_verbose() a second time after elf_init() (First call happens within elf_init()). Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> Keir: Can you also apply changeset 15672 and this patch to Xen

Hello, I am receiving this error: assert(Slot != -1 && "Value in symtab but has no slot number!!"); While trying to generate a module at run time using LLVM classes. Specifically with an instance of StoreInst class. After I generate all the instructions, I try to save the Module to bytecode, but I receive that error in the method 'outputSymbolTable' Does anyone

The first layout is older, and the second is newer. Going forward, things are likely to move around. The second layout is more flexible because it doesn't put any repo inside another repo, so I would recommend adopting it. At the very least, using it will put you in a good position to adapt to any future layout changes. On Mon, Feb 19, 2018 at 1:36 AM Liad Mordekoviz via llvm-dev <

Hi Ricardo, Yes, its because you have an invalid module. You should run Module::verify before attempting to write the bytecode. This will pinpoint the problem for you. However, I think I know what's going on: you've left an object (a Value not a Type) in the symbol table that is not in the Module. Not quite sure how you do that, but I suppose its possible if you manipulated the symbol

According to https://reviews.llvm.org/D88348#2344466, that diff should fix the failure. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Fāng-ruì Sòng via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Fāng-ruì Sòng <maskray at google.com> Date: Tuesday, November 10, 2020 at 10:13 PM To: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Cc: Nico

Hi Reid, Thanks for your help! I could detect the problem and the module now can be saved (it was a problem with some Alloca instructions). I could not find a "verify" method in the Module class, but just for the records, I did this: --------------- PassManager Passes; // Add an appropriate TargetData instance for this module... Passes.add(new TargetData("save",

Hello, We've recently started using ifuncs in the x86(_64) FreeBSD kernel. Currently lld will emit a PLT entry for each ifunc, so ifunc calls are more expensive that those of regular functions. In our kernel, this overhead isn't really necessary: if lld instead emits PC-relative relocations for each ifunc call site, where each relocation references a symbol of type GNU_IFUNC, then during

This adds [f]getc() and fgets() for parsing config files. Probably hard to avoid. Still trying to decide if I actually want to add system() or not. -hpa

On Fri, May 15, 2015 at 5:11 AM, Dave Bozier <seifsta at gmail.com> wrote: > > Are you sure about the additional I/O? With native symtab, existing > tools just need to read those, while plugin based approach needs to read > bit code section to feedback symbols to the tool. > > The additional I/O will be quite big if you are going to emit the full > symbol table. Looking

When LLD builds a shared library for x86_64 it puts _GLOBAL_OFFSET_TABLE_ to the both .symtab and .dynsym and defines it as a GLOBAL symbol. If later this shared library participates in executable file linking and GNU BFD linked is used for that, this linker shows an error: /usr/bin/ld: a.out: hidden symbol `_GLOBAL_OFFSET_TABLE_' in /usr/lib/x86_64-linux-gnu/crt1.o is referenced by DSO Gold

Hi, I am trying to write a simple interpreter. I am trying to generate LLVM IR for assignment operation. The code for the generation part looks like this llvm::Value* codeGenSymTab(llvm::LLVMContext& context) { > printf("\n CodeGen SymTab \n"); > Value *num = ConstantInt::get(Type::getInt64Ty(context), aTable.value, > true); > Value *alloc = new

Great, thanks! Those results are about roughly what I was expecting. I assume "compilation time" is actually just the link time? I find it particularly interesting that the DWARFLinker rewriting solution produces the same size improvement in .debug_line as the fragmented DWARF approach. That suggests that in that case, fragmented DWARF output is probably about as optimal as it can get.

Hi, We are trying to use clang as a drop-in replacement for the gcc come with Android NDK. I found that MC/ELF doesn't not handle Thumb functions properly, e.g., bit 0 of the function name in the .symtab is not set to 1, and some thumb instructions are not generated correctly, e.g., the addresses for tBL/tBLX are not calculated right. With that attached patch, we can compile and run some