Re: [lldb-dev] [llvm-dev] [3.7 Release] Release Candidate 2 available
Just found out that all documentation and html refer to an old mailing lists. Probably, commits 243999-244010 needs to be picked up into release_37 as well. List of commits, just in case: http://llvm.org/viewvc/llvm-project?view=revision&revision=243999 http://llvm.org/viewvc/llvm-project?view=revision&revision=244000 http://llvm.org/viewvc/llvm-project?view=revision&revision=244001 http://llvm.org/viewvc/llvm-project?view=revision&revision=244002 http://llvm.org/viewvc/llvm-project?view=revision&revision=244003 http://llvm.org/viewvc/llvm-project?view=revision&revision=244004 http://llvm.org/viewvc/llvm-project?view=revision&revision=244005 http://llvm.org/viewvc/llvm-project?view=revision&revision=244006 http://llvm.org/viewvc/llvm-project?view=revision&revision=244007 http://llvm.org/viewvc/llvm-project?view=revision&revision=244008 http://llvm.org/viewvc/llvm-project?view=revision&revision=244009 http://llvm.org/viewvc/llvm-project?view=revision&revision=244010 -- AlexDenisov Software Engineer, http://lowlevelbits.org > On 12 Aug 2015, at 02:32, Hans Wennborg via llvm-dev > wrote: > > Hello everyone, > > Source, binaries and docs for LLVM 3.7.0-rc2 are now available at > http://llvm.org/pre-releases/3.7.0/ > > Please try them out, run tests, build your favourite projects, and > *file bugs* reporting any issues that you find. > > We are now getting into the part of the release process where it's > time to wrap things up, so if you were thinking about doing some tests > or getting something fixed before the release, this is the time. > > Thanks, > Hans > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org http://llvm.cs.uiuc.edu > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [RFC] Simplifying logging code
Hi All, At the moment logging in LLDB done in the following way: Log* log = GetLogIfAllCategoriesSet(...); if (log) log->Printf(...); This approach is clean and easy to understand but have the disadvantage of being a bit verbose. What is the general opinion about changing it to something like this? Logger log = GetLogIfAllCategoriesSet(...); log.Printf(...); The idea would be to return a new type of object from GetLogIfAllCategoriesSet with small size (size of a pointer) what will check if the log category is enabled. From efficiency perspective this change would have no effect and it will simplify the writing of the logging statements. Implementation details: Logger would just contain a pointer to a Log object and forward all call to that object if that one isn't null. Additionally it will have a method to check for nullness of the underlying log object if we want to do some calculation only if the logging is enabled. Thanks, Tamas P.S.: Other possible simplification in the logging system would be to use LogIfAllCategoriesSet but it require the specification of the log channel at each call and have a very minor overhead because of checking for the enabled log categories at each call. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Simplifying logging code
From an efficiency perspective, the arguments to Printf will still need to be evaluated. Some of those arguments touch multiple areas and will require significant effort to change into a new format, which is essentially the exact same as we have now. Was there not a decision to stick with what we have now when this came up a few weeks ago? Clean and easy to understand over verbose any day of the week in my view. Colin On 12/08/2015 11:52, Tamas Berghammer via lldb-dev wrote: Hi All, At the moment logging in LLDB done in the following way: Log* log = GetLogIfAllCategoriesSet(...); if (log) log->Printf(...); This approach is clean and easy to understand but have the disadvantage of being a bit verbose. What is the general opinion about changing it to something like this? Logger log = GetLogIfAllCategoriesSet(...); log.Printf(...); The idea would be to return a new type of object from GetLogIfAllCategoriesSet with small size (size of a pointer) what will check if the log category is enabled. From efficiency perspective this change would have no effect and it will simplify the writing of the logging statements. Implementation details: Logger would just contain a pointer to a Log object and forward all call to that object if that one isn't null. Additionally it will have a method to check for nullness of the underlying log object if we want to do some calculation only if the logging is enabled. Thanks, Tamas P.S.: Other possible simplification in the logging system would be to use LogIfAllCategoriesSet but it require the specification of the log channel at each call and have a very minor overhead because of checking for the enabled log categories at each call. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- - Colin Riley Senior Director, Parallel/Graphics Debugger Systems Codeplay Software Ltd 45 York Place, Edinburgh, EH1 3HP Tel: 0131 466 0503 Fax: 0131 557 6600 Website: http://www.codeplay.com Twitter: https://twitter.com/codeplaysoft This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated. As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments. Company registered in England and Wales, number: 04567874 Registered office: 81 Linkfield Street, Redhill RH1 6BY ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Simplifying logging code
I don't remember to any discussion about it but I might just missed it (don't see it in the archive either). >From the efficiency perspective in most of the case evaluating the arguments for Printf should be very fast (printing local variable) and the few case where it isn't the case we can keep the condition (using "if (log.Enabled()) log.Printf()"). From readability perspective I think ignoring the "if (log)" in most of the case won't hurt and it will eliminate the possibility of missing a check what will cause a crash. Tamas On Wed, Aug 12, 2015 at 1:37 PM Colin Riley via lldb-dev < lldb-dev@lists.llvm.org> wrote: > From an efficiency perspective, the arguments to Printf will still need to > be evaluated. Some of those arguments touch multiple areas and will require > significant effort to change into a new format, which is essentially the > exact same as we have now. > > Was there not a decision to stick with what we have now when this came up > a few weeks ago? Clean and easy to understand over verbose any day of the > week in my view. > > Colin > > > > On 12/08/2015 11:52, Tamas Berghammer via lldb-dev wrote: > > Hi All, > > At the moment logging in LLDB done in the following way: > Log* log = GetLogIfAllCategoriesSet(...); > if (log) > log->Printf(...); > > This approach is clean and easy to understand but have the disadvantage of > being a bit verbose. What is the general opinion about changing it to > something like this? > Logger log = GetLogIfAllCategoriesSet(...); > log.Printf(...); > > The idea would be to return a new type of object from > GetLogIfAllCategoriesSet with small size (size of a pointer) what will > check if the log category is enabled. From efficiency perspective this > change would have no effect and it will simplify the writing of the logging > statements. > > Implementation details: > Logger would just contain a pointer to a Log object and forward all call > to that object if that one isn't null. Additionally it will have a method > to check for nullness of the underlying log object if we want to do some > calculation only if the logging is enabled. > > Thanks, > Tamas > > P.S.: Other possible simplification in the logging system would be to > use LogIfAllCategoriesSet but it require the specification of the log > channel at each call and have a very minor overhead because of checking for > the enabled log categories at each call. > > > ___ > lldb-dev mailing > listlldb-...@lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > -- > - Colin Riley > Senior Director, > Parallel/Graphics Debugger Systems > > Codeplay Software Ltd > 45 York Place, Edinburgh, EH1 3HP > Tel: 0131 466 0503 > Fax: 0131 557 6600 > Website: http://www.codeplay.com > Twitter: https://twitter.com/codeplaysoft > > This email and any attachments may contain confidential and /or privileged > information and is for use by the addressee only. If you are not the intended > recipient, please notify Codeplay Software Ltd immediately and delete the > message from your computer. You may not copy or forward it,or use or disclose > its contents to any other person. Any views or other information in this > message which do not relate to our business are not authorized by Codeplay > software Ltd, nor does this message form part of any contract unless so > stated. > As internet communications are capable of data corruption Codeplay Software > Ltd does not accept any responsibility for any changes made to this message > after it was sent. Please note that Codeplay Software Ltd does not accept any > liability or responsibility for viruses and it is your responsibility to scan > any attachments. > Company registered in England and Wales, number: 04567874 > Registered office: 81 Linkfield Street, Redhill RH1 6BY > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Simplifying logging code
We could solve booth the efficiency concerns and the conciseness with a macro. (Gasp!) ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [3.7 Release] Release Candidate 2 available
On Wed, Aug 12, 2015 at 2:33 AM, AlexDenisov <1101.deb...@gmail.com> wrote: > Just found out that all documentation and html refer to an old mailing lists. > Probably, commits 243999-244010 needs to be picked up into release_37 as well. Thanks! These have now been merged to 3.7. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Simplifying logging code
The previous discussion (with patch) was here: http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20150427/018839.html Jim > On Aug 12, 2015, at 6:11 AM, Vince Harron via lldb-dev > wrote: > > We could solve booth the efficiency concerns and the conciseness with a > macro. (Gasp!) > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Simplifying logging code
After the previous discussion I agree that evaluating the arguments is unacceptable. But you are correct here that a macro would solve this. In fact, most C++ log libraries use macros I guess for this very reason. I decided to make some macros for the windows plugin which you can look at it in ProcessWindowsLog.h. There are some issues that are not obvious how to solve though. For example, the macros I wrote in ProcessWindowsLog cannot be used outside of my plugin. This is because each plugin statically defines its own channels as well as defines its own global Log object. If this were to be done in a way that there were one set of macros that all current and future generic code and plugins could use, I think it would require a fairly substantial refactor. On Wed, Aug 12, 2015 at 6:11 AM Vince Harron via lldb-dev < lldb-dev@lists.llvm.org> wrote: > We could solve booth the efficiency concerns and the conciseness with a > macro. (Gasp!) > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DNBConfig and debugserver
Yep, removing it seems like a good solution. And please do feel free to add any newlines and any files that are missing them without need for reviews. > On Aug 11, 2015, at 9:21 PM, Bruce Mitchener via lldb-dev > wrote: > > Hello! > > This is probably for the Apple People since it relates to debugserver... > > I was going to fix an issue with the cmake build on Mac OS X related to the > mig generation step and DNBConfig.h, but when I started digging into things, > I noticed that DNBConfig.h isn't needed any longer. > > The only test that it performs is for whether or not 64 bit Mach exceptions > can be used. > > The code that actually handled non-64 bit Mach exceptions was removed in 2011 > by this commit: > > commit 0e8147bd867e4cdaae9400f56d02c7aacd40a9b3 > Author: Greg Clayton > Date: Fri Oct 28 22:59:14 2011 + > > Enabled the "printf" attribute on all debugserver logging functions and > fixed > the ensuing mayhem. > > > > git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@143244 > 91177308-0d34-0410-b5e6-96231b3b80d8 > > So, I'm wondering what the right next step is: > > • Just fix the issue that I was going to fix in the cmake build system. > • Remove the unused test for 64 bit Mach exception handling and that > usage of DNBConfig.h > • Remove DNBConfig.h entirely along with the machinery for generating > it since nothing actually needs or uses it. > • Something else. > I'm happy to do any of the above options. > > Cheers, > > - Bruce > > PS. HavAVX.s is missing an EOL at EOF, and so it generates a warning. Can I > just commit an EOL at EOF without going through Phabricator? That won't break > anything, right? > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
