Carter Cheng via llvm-dev
2019-Jul-05 08:05 UTC
[llvm-dev] Allocating shadow tables at the bottom of memory on Linux.
Hello, I have been working on a llvm instrumentation pass as an exercise to get up to speed on how llvm operates. I am curious about what the best way would be to create a shadow table at a fixed address in low memory starting at 0x10000 and extending upwards. I am unclear about the correct approach from looking at the DataFlowSanitizer since getOrInsertGlobal seems to be used on a limited number of times in runModule primarily to allocate thread local storage and I am uncertain how the code ensures that the runtime metadata doesnt get overwritten by alloca calls for the stack. Thanks in advance, Carter. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190705/c558b585/attachment.html>
Tim Northover via llvm-dev
2019-Jul-05 08:25 UTC
[llvm-dev] Allocating shadow tables at the bottom of memory on Linux.
Hi Carter, On Fri, 5 Jul 2019 at 09:05, Carter Cheng via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I have been working on a llvm instrumentation pass as an exercise to get up to speed on how llvm operates. I am curious about what the best way would be to create a shadow table at a fixed address in low memory starting at 0x10000 and extending upwards.Normally you'd put your data into a custom named section and then tell the linker to put that section at a specific address through either command-line options or a linker script.> I am uncertain how the code ensures that the runtime metadata doesnt get overwritten by alloca calls for the stack.If the value is a global it'll pretty much automatically be handled by the linker and OS. The stack is usually pretty small and can be placed out of the way of any allocation the OS knows about (and it knows about all of them because it has to actually do the allocation at the end of the day). I think some sanitizers have a runtime that takes over the stack and heap though and allocate both the "real" memory and its shadow together. See compiler-rt/lib/asan for example. Cheers. Tim.> > Thanks in advance, > > Carter. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Carter Cheng via llvm-dev
2019-Jul-05 11:30 UTC
[llvm-dev] Allocating shadow tables at the bottom of memory on Linux.
Great, thanks for the info! On Fri, Jul 5, 2019 at 4:25 PM Tim Northover <t.p.northover at gmail.com> wrote:> Hi Carter, > > On Fri, 5 Jul 2019 at 09:05, Carter Cheng via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I have been working on a llvm instrumentation pass as an exercise to get > up to speed on how llvm operates. I am curious about what the best way > would be to create a shadow table at a fixed address in low memory starting > at 0x10000 and extending upwards. > > Normally you'd put your data into a custom named section and then tell > the linker to put that section at a specific address through either > command-line options or a linker script. > > > I am uncertain how the code ensures that the runtime metadata doesnt get > overwritten by alloca calls for the stack. > > If the value is a global it'll pretty much automatically be handled by > the linker and OS. The stack is usually pretty small and can be placed > out of the way of any allocation the OS knows about (and it knows > about all of them because it has to actually do the allocation at the > end of the day). > > I think some sanitizers have a runtime that takes over the stack and > heap though and allocate both the "real" memory and its shadow > together. See compiler-rt/lib/asan for example. > > Cheers. > > Tim. > > > > Thanks in advance, > > > > Carter. > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190705/5ab81f52/attachment.html>