search for: begin_symbol

Displaying 8 results from an estimated 8 matches for "begin_symbol".

Did you mean: begin_symbols
2013 Aug 02
5
[LLVMdev] Coding Standards: Iterator begin and end functions.
...push_back(), etc...). But different parts of llvm have different opinions on how to handle the related case of classes that are not STL like, but have multiple collections that can be iterated over. * llvm/IR uses global_begin, alias_begin, etc. I.E., singular name + _begin(). * llvm/Object uses begin_symbols, begin_sections, etc. I.E, begin_ + plural name. * others (YAML, LoopIterator) use beginSequence, beginFlowSequence, etc. I would like to propose adding the the format used by llvm/IR to the coding standard since it seems to be the most common. Cheers, Rafael
2013 Aug 02
0
[LLVMdev] Coding Standards: Iterator begin and end functions.
...ifferent parts of llvm have different opinions on how to handle > the related case of classes that are not STL like, but have multiple > collections that can be iterated over. > > * llvm/IR uses global_begin, alias_begin, etc. I.E., singular name + > _begin(). > * llvm/Object uses begin_symbols, begin_sections, etc. I.E, begin_ + > plural name. > * others (YAML, LoopIterator) use beginSequence, beginFlowSequence, etc. > > I would like to propose adding the the format used by llvm/IR to the > coding standard since it seems to be the most common. > Please do so. That is...
2013 Nov 13
2
[LLVMdev] Stack traces from JIT code
Hi Andy, In the NotifyObjectEmitted method of our derived JITEventListener class we use the begin_symbol() iterator to walk the object's symbols looking for functions and only functions marked with ExternalLinkage seem to show up. I'm not sure how I would access the Dwarf info from within there, is there a way? Thanks, Andrew On Wed, Nov 13, 2013 at 8:23 PM, Kaylor, Andrew <andrew.kaylor...
2013 Nov 13
0
[LLVMdev] Stack traces from JIT code
...Andrew MacPherson [mailto:andrew.macp at gmail.com] Sent: Wednesday, November 13, 2013 1:12 PM To: Kaylor, Andrew Cc: Reid Kleckner; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces from JIT code Hi Andy, In the NotifyObjectEmitted method of our derived JITEventListener class we use the begin_symbol() iterator to walk the object's symbols looking for functions and only functions marked with ExternalLinkage seem to show up. I'm not sure how I would access the Dwarf info from within there, is there a way? Thanks, Andrew On Wed, Nov 13, 2013 at 8:23 PM, Kaylor, Andrew <andrew.kaylor...
2013 Aug 02
0
[LLVMdev] Coding Standards: Iterator begin and end functions.
...ut different parts of llvm have different opinions on how to handle > the related case of classes that are not STL like, but have multiple > collections that can be iterated over. > > * llvm/IR uses global_begin, alias_begin, etc. I.E., singular name + _begin(). > * llvm/Object uses begin_symbols, begin_sections, etc. I.E, begin_ + > plural name. > * others (YAML, LoopIterator) use beginSequence, beginFlowSequence, etc. > > I would like to propose adding the the format used by llvm/IR to the > coding standard since it seems to be the most common. +1 -Chris
2013 Nov 13
0
[LLVMdev] Stack traces from JIT code
>From NotifyObjectEmitted you should be able to get to any function that's visible via either the ELF headers or the DWARF information. Do you have functions that don't show up in either of those places? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew MacPherson Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc:
2013 Nov 13
3
[LLVMdev] Stack traces from JIT code
We implemented a similar solution for handling crashes in production but one issue we came across with MCJIT was that the NotifyFunctionEmitted call from the old JIT was replaced with NotifyObjectEmitted. The ObjectImage used by NotifyObjectEmitted does have a way of iterating symbols but non-external functions used in the module didn't seem to appear in this list so we were left with some
2014 Oct 19
14
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
I've just wasted a day chasing my tail because of subtleties introduced to handle the optionality of the DataLayout. I would like to never do this again. =] We now have this attached to the Module with just a flimsy faked-up pass to keep APIs consistent. So, is there any problem with beginning down the path of: 1) Synthesizing a "default" boring DataLayout for all modules that