similar to: [LLVMdev] Proposal: function prefix data

On Wed, Jul 17, 2013 at 9:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > To maintain the semantics of ordinary function calls, the prefix data > must have a particular format. Specifically, it must begin with a > sequence of bytes which decode to a sequence of machine instructions, > valid for the module's target, which transfer control to the point >

As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr. An alternative you could use is, instead of using the function pointer as the variable where you are referring to a

On Wed, Jul 17, 2013 at 6:06 PM, Peter Collingbourne <peter at pcc.me.uk>wrote: > Hi, > > I would like to propose that we introduce a mechanism in IR to allow > arbitrary data to be stashed before a function body. The purpose of > this would be to allow additional data about a function to be looked > up via a function pointer. Two use cases come to mind: > > 1)

On Wed, Jul 17, 2013 at 07:50:58PM -0700, Sean Silva wrote: > On Wed, Jul 17, 2013 at 6:06 PM, Peter Collingbourne <peter at pcc.me.uk>wrote: > > > Hi, > > > > I would like to propose that we introduce a mechanism in IR to allow > > arbitrary data to be stashed before a function body. The purpose of > > this would be to allow additional data about a

On Thu, Jul 18, 2013 at 12:13 PM, Peter Collingbourne <peter at pcc.me.uk>wrote: > On Wed, Jul 17, 2013 at 07:50:58PM -0700, Sean Silva wrote: > > On Wed, Jul 17, 2013 at 6:06 PM, Peter Collingbourne <peter at pcc.me.uk > >wrote: > > > > > Hi, > > > > > > I would like to propose that we introduce a mechanism in IR to allow > > >

On Mon, Mar 6, 2017 at 5:54 PM, Moritz Angermann <moritz.angermann at gmail.com > wrote: > Hi Peter, > > I’ve just experimented with this a bit: > > Say we would end up with the following assembly: > > .section __TEXT,__text > .globl _main > > .long 1 > _main: > inc %eax > ret > > .globl _main.dsp > .alt_entry _main.dsp

Firstly, do you need "main.dsp" defined as an external symbol, or can all external references go via "main"? If the answer is the latter, that will make the solution simpler. If only the latter, you will need to make a change to LLVM here: http://llvm-cs.pcc.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650 Basically you would need to add a hook to the TargetLoweringObjectFile

I suspect that the format isn't important if you do that, but I wouldn't recommend it, at least because inlining (and other inter-procedural optimizations) are not expected to work correctly if you produce IR like that. Peter On Mon, Mar 6, 2017 at 6:44 PM, Moritz Angermann <moritz.angermann at gmail.com > wrote: > Peter, > > thanks again! Yes, we only need to refer to

That is in theory what omitting the .subsections_via_symbols directive is supposed to do, but in an experiment I ran a year or two ago I found that the Mach-O linker was still dead stripping on symbol boundaries with this directive omitted. In any case, a more precise approach has more recently (~a few months ago) become possible. There is a relatively new asm directive called .altentry that, as

Somehow this cover letter was dropped from my symbol offsets patch set: 1. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073200.html 2. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073201.html Original message ----------------- About a year ago a proposal suggesting symbol offsets was brought to this list[1]. This proposal goes hand-in-hand with the prefix data proposal[2]

systemd allows sockets passed through socket activation to be named with the protocol they require. We only ever pass one socket, name it. This environment variable is currently ignored by qemu-nbd and nbdkit, but might be used by qemu-storage-daemon: https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg06114.html --- generator/states-connect-socket-activation.c | 41

Hi, I decided to implement a sanitizer that tracks the active member, and reports reads from inactive members. e.g.: struct S { union { long l; char s[42]; double d; }; }; void f() { S s; s.d = 42.0; if (s.l > 100) // fire here ; } My current implementation is naïve (also possibly wrong), and doesn't care about "special

Hi - Not sure if anyone else saw this or cares about a decompiler (not personally tested) https://github.com/draperlaboratory/fracture I wonder if they have been in contact with anyone in the community in getting this upstreamed. Does it look interesting to anyone else? (thoughts/random comments/feedback)

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

On Thu, Apr 3, 2014 at 11:50 AM, Jevin Sweval <jevinsweval at gmail.com> wrote: > On Wed, Apr 2, 2014 at 1:57 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: >> Hi - >> >> Not sure if anyone else saw this or cares about a decompiler (not personally >> tested) >> https://github.com/draperlaboratory/fracture >> >> I wonder if

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

On 1/28/23 13:47, Richard W.M. Jones wrote: > systemd allows sockets passed through socket activation to be named > with the protocol they require. We only ever pass one socket, name > it. This environment variable is currently ignored by qemu-nbd and > nbdkit, but might be used by qemu-storage-daemon: > > https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg06114.html

Dear all, I use the clang frontend to produce the control flow graph of a C program through this command: clang -Xclang -analyze -Xclang -analyzer-checker=debug.DumpCFG test.c The produced information contains all the basic blocks identified by labels, e.g. B1, B2, etc. along with their predecessors and successors. Is there a way to get the starting address of each of these basic block? I would

> On Mar 6, 2017, at 7:56 PM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh, that's great that it's possible to implement properly, now. Does it actually work for > > It'd be cool if LLVM hooked up its generic section handling support to this feature now, so that the only global symbols that *didn't* get marked as .alt_entry were

The only VHDL to LLVM project that I know of is nvc. [0] I haven't tried it personally and from a cursory look through the source it seems like there is a LLVM backend and a "native" backend (not sure what that means). If you're really crazy you might want to see if you could massage GHDL [1] (VHDL GCC frontend) + DragonEgg [2] (LLVM backend for GCC) to get you LLVM IR. I'm