On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote:> Hi Talin, > >> Really, all I need to make this work is some way to 'mark' a global so that my >> custom pass can query for all marked globals. Any ideas on this? > > metadata maybe?A better approach would be to create an global array of strings to hold names of marked globals. You know the name of this special array and use it to query all marked globals. This is the trick llvm-gcc uses to support PCH. - Devang
On Tue, Jan 25, 2011 at 9:14 AM, Devang Patel <dpatel at apple.com> wrote:> > On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote: > > > Hi Talin, > > > >> Really, all I need to make this work is some way to 'mark' a global so > that my > >> custom pass can query for all marked globals. Any ideas on this? > > > > metadata maybe? > > A better approach would be to create an global array of strings to hold > names of marked globals. You know the name of this special array and use it > to query all marked globals. This is the trick llvm-gcc uses to support PCH. >OK thanks, I'll try that :)> > - > Devang > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110125/bec3c3e5/attachment.html>
On Tue, Jan 25, 2011 at 9:14 AM, Devang Patel <dpatel at apple.com> wrote:> > On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote: > > > Hi Talin, > > > >> Really, all I need to make this work is some way to 'mark' a global so > that my > >> custom pass can query for all marked globals. Any ideas on this? > > > > metadata maybe? > > A better approach would be to create an global array of strings to hold > names of marked globals. You know the name of this special array and use it > to query all marked globals. This is the trick llvm-gcc uses to support PCH. > > Actually, the ability to attach metadata nodes to globals would be acleaner way to do this - and it sounds like it would fit your use case as well, plus others that I can think of, such as annotation processing.> - > Devang > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110127/d9a6b4db/attachment.html>
On Tue, Jan 25, 2011 at 9:14 AM, Devang Patel <dpatel at apple.com> wrote:> > On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote: > > > Hi Talin, > > > >> Really, all I need to make this work is some way to 'mark' a global so > that my > >> custom pass can query for all marked globals. Any ideas on this? > > > > metadata maybe? > > A better approach would be to create an global array of strings to hold > names of marked globals. You know the name of this special array and use it > to query all marked globals. This is the trick llvm-gcc uses to support PCH. >So, I spent the better part of a day making sure that each and every static global had a well-formed and unique name. So far so good. However, It turns out that what I need is a little different than what I described - I not only need to know which globals should be traced, but I also need to associate with each of these globals a data structure that tells the garbage collector how to trace it. Let me describe the setup: For each compiled module, the compiler generates a list of all statically allocated data structures in the module. Each list entry is a 2-tuple containing a pointer to the static global and a pointer to the trace table for that global. Globals that have the same type will share the same trace table. OK so what I need to have happen at link time is the following: -- Run the dead global elimination pass to determine which globals will be included in the final output. -- For the globals that remain, find the trace table pointer that was originally associated with that global. -- Collect the globals and their associated table pointers into a list of tuples, which is given to the garbage collector as a parameter on startup. There are a couple of steps in the above that aren't quite clear to me. The main problem is that I don't want the trace tables themselves to be eliminated by the dead global elimination pass - or conversely, if they are eliminated, I need a way to add them back into the module again. This also includes any function pointers embedded in the trace table structures, which might have been considered dead when the trace table was dead. In other words, what I'd like to be able to do is run the dead global elimination pass without considering the trace tables at all, and then once I know which globals are live, go ahead and re-associate the trace table with each global, and then re-run the dead global pass to remove any trace tables that weren't referred to. Any suggestions would be welcome. I'm otherwise very close to getting a simple, non-shadow-stack collector working :) -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110130/6175f5a2/attachment.html>
On Jan 30, 2011, at 8:36 PM, Talin wrote:> So, I spent the better part of a day making sure that each and every static global had a well-formed and unique name. So far so good. > > However, It turns out that what I need is a little different than what I described - I not only need to know which globals should be traced, but I also need to associate with each of these globals a data structure that tells the garbage collector how to trace it. > > Let me describe the setup: For each compiled module, the compiler generates a list of all statically allocated data structures in the module. Each list entry is a 2-tuple containing a pointer to the static global and a pointer to the trace table for that global. Globals that have the same type will share the same trace table. > > OK so what I need to have happen at link time is the following: > > -- Run the dead global elimination pass to determine which globals will be included in the final output. > -- For the globals that remain, find the trace table pointer that was originally associated with that global. > -- Collect the globals and their associated table pointers into a list of tuples, which is given to the garbage collector as a parameter on startup.You could use metadata to hold this list of tuples. If you create this list before running dead global elimination pass then the optimizer won't see this metadata and any globals that are deleted will be turned into null in your tuple.> There are a couple of steps in the above that aren't quite clear to me. The main problem is that I don't want the trace tables themselves to be eliminated by the dead global elimination pass - or conversely, if they are eliminated, I need a way to add them back into the module again. This also includes any function pointers embedded in the trace table structures, which might have been considered dead when the trace table was dead. > > In other words, what I'd like to be able to do is run the dead global elimination pass without considering the trace tables at all, and then once I know which globals are live, go ahead and re-associate the trace table with each global, and then re-run the dead global pass to remove any trace tables that weren't referred to. > > Any suggestions would be welcome. I'm otherwise very close to getting a simple, non-shadow-stack collector working :) >- Devang