http://permalink.gmane.org/gmane.comp.debugging.lldb.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1651 <pre>Hi, I have attached a patch for a bug in Variable::GetValuesForVariableExpressionPath(). There is also a small patch for a typo. Can you please review them? Thanks, Yacine _______________________________________________ lldb-dev mailing list lldb-dev&lt; at &gt;cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev </pre> Yacine Belkadi 2013-05-18T09:00:39 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1650 <pre>It's possible others aren't seeing this but on Ubuntu 12.04 64 bits, when I exit lldb I get a few randomish garbage characters spewed to the terminal. It appears the problem is the shutdown of master_out_comm in tools/driver/Driver.cpp around line 1591. But I'm not sure I know enough about how this works to say what I'm doing to fix it is the best solution. Other code for handling a Communication clear appears to shut them down by doing the following: SetReadThreadBytesReceivedCallback (NULL, NULL); Disconnect (NULL); StopReadThread (NULL); Using this sequence on the master_out_comm seems to stop it from spewing random characters while quiting. Just stoping the read thread wasn't a good solution, since it caused a huge pause. Had to set the callback to NULL and disconnect first. It also seemed kind of odd to me that you are closing the editline_output_pty before shutting down master_out_comm and out_comm_2 (which both were passed the editline file descriptor). So I moved that CloseMasterFi</pre> Matthew Sorrels 2013-05-17T21:39:36 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1649 <pre>I have LLDB close to building with gcc-4.7 on Ubuntu without needing it to be the default compiler. The issue I ran into was that there are places that check for g++ being the compiler and add extra flags if the name is exactly "g++" There is some Makefile code that does: ifeq (g++,$(shell basename $(CXX))) do stuff endif If there a good makefile mechanism to say if the basename starts with "g++"? I know I can probably pass this through "colrm", but I didn't know if there is a common other way that this kind of thing should be done. Right now to get things building I just did: ifeq (g++,$(shell basename $(CXX))) do stuff endif ifeq (g++-4.7,$(shell basename $(CXX))) do stuff endif But I don't want to check this in as the fix should really work for any GCC. Greg Clayton </pre> Greg Clayton 2013-05-17T19:16:31 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1648 <pre>Thanks for the clarification. I’ve closed the bug after confirming my test works when not in async mode. However, in async mode what do I need to do to handle the stop events? I have a loop that polls for events, and I see 0x7f965c000940 Event: broadcaster = 0x2a8c488 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x2a8c450 (pid = 31924), state = stopped} After I call ‘run’, and it hits the breakpoint. What needs to be updated at this point to allow me to ‘continue’? Thanks, Ben From: bugzilla-daemon&lt; at &gt;llvm.org [mailto:bugzilla-daemon&lt; at &gt;llvm.org] Sent: Thursday, May 16, 2013 7:07 PM To: Langmuir, Ben Subject: [Bug 16039] Cannot use 'continue' from the python api on Linux Jim Ingham&lt;mailto:jingham&lt; at &gt;apple.com&gt; changed bug 16039&lt;http://llvm.org/bugs/show_bug.cgi?id=16039&gt; What Removed Added CC jingham&lt; at &gt;apple.com&lt;mailto:jingham&lt; at &gt;apple.com&gt; Comment # 2&lt;http://llvm.org/bugs/show_bug.cgi?id=16039#c2&gt; on bug 16039&lt;http://llvm.org/bugs/show_bug.</pre> Langmuir, Ben 2013-05-17T18:36:47 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1646 <pre>Hello, Plugged in the Jenkins instance used to build Debian &amp; Ubuntu nightly package, I configured a code coverage tool (lcov) with all the tests of these projects. Results are published here: http://buildd-clang.debian.net/coverage/ This URL is updated twice a day (it might change since it is taking a long time). For those who would like to have their own setup, with gcc, use the following declaration: CXXFLAGS="-fprofile-arcs -ftest-coverage" LDFLAGS="-coverage -lgcov" Rebuild everything, launch the tests and run: REPORT=reports/scilab-code-coverage.info BUILD_DIR=reports/ mkdir -p $BUILD_DIR lcov --directory $BUILD_DIR --capture --ignore-errors source --output-file $REPORT lcov --remove $REPORT "/usr*" -o $REPORT lcov --remove $REPORT "$BUILD_DIR/*" -o $REPORT genhtml -o reports/coverage --show-details --highlight --legend $REPORT Cheers, Sylvestre </pre> Sylvestre Ledru 2013-05-17T15:09:56 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1645 <pre>I agree with what you said, and the patches look good. A few inlined comments below... On May 16, 2013, at 3:38 PM, Michael Sartain &lt;mikesart&lt; at &gt;valvesoftware.com&gt; wrote: Yep, the PlatformLinux needs to be able to deal with "unknown unknown" properly which your patch does do. The patch looks good. </pre> Greg Clayton 2013-05-16T23:05:10 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1644 <pre> Getting there. :) I want to be really clear, so I'm going to break this up as this issue involves the ObjectFileELF::GetModuleSpecifications() changes - we can assume GetProcessCPUTypeFromExecutable() and friends don't even exist... Here is the trace of what is happening right now when it fails. calls TargetList::CreateTarget(), line 63 - platform_arch defaults to unknown/unknown/unknown calls ObjectFile::GetModuleSpecifications() - only one arch, so platform_arch is set to it (x86_64/unknownOS/UnknownEnv) calls TargetList::CreateTarget, line 187 - specified_arch == platform_arch == (x86_64/unknownOS/UnknownEnv) calls Platform::ResolveExecutble() - exe_arch == (x86_64/unknownOS/UnknownEnv) - module_spec is intialized with exe_arch if (exe_arch.IsValid()) is true so: calls ModuleList::GetSharedModule(module_spec, ...) Given what you've said, I believe I need to add some code somewhere in that call chain which checks for triple vendor not being sp</pre> Michael Sartain 2013-05-16T22:38:05 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1643 <pre>http://llvm.org/bugs/show_bug.cgi?id=16039 Bug ID: 16039 Summary: Cannot use 'continue' from the python api on Linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev&lt; at &gt;cs.uiuc.edu Reporter: ben.langmuir&lt; at &gt;intel.com Classification: Unclassified Created attachment 10530 --&gt; http://llvm.org/bugs/attachment.cgi?id=10530&amp;action=edit Python script to reproduce the bug Trying to continue from the python api erroneously fails saying the process is still running. This is true with the command interpreter, and using Process.Continue(). To reproduce, compile test.c with -g and save as a.out, then run the python script. interp.HandleCommand('b main', res) interp.HandleCommand('run', res) interp.HandleCommand('process status', res) print res.GetOutput() interp.HandleCommand('continue', res) if re</pre> bugzilla-daemon< at >llvm.org 2013-05-16T21:23:18 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1642 <pre>http://llvm.org/bugs/show_bug.cgi?id=16037 Bug ID: 16037 Summary: Expression evaluation for function call to templated class doesn't work Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev&lt; at &gt;cs.uiuc.edu Reporter: tareq.a.siraj&lt; at &gt;intel.com Classification: Unclassified Created attachment 10528 --&gt; http://llvm.org/bugs/attachment.cgi?id=10528&amp;action=edit Reproducer source Expression evaluation for a function call to a templated class seems to be broken unless the same expression is used later in the body. Not sure if this is a duplicate of 15879 or not. Source: struct Foo { }; template &lt;typename T&gt; class Ptr { T Val; public: Ptr() : Val(T()) {} Ptr(T x) : Val(x) {} T get() const { return Val; } }; typedef Ptr&lt;Foo*&gt; FooResult; int main(void) { FooResult f = n</pre> bugzilla-daemon< at >llvm.org 2013-05-16T20:52:59 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1641 <pre>Hi, thanks for addressing these concerns and for your contribution to LLDB. Please find replies inlined. Enrico Granata 📩 egranata&lt; at &gt;.com ☎️ 27683 On May 16, 2013, at 1:13 PM, Yacine Belkadi &lt;yacine.belkadi.1&lt; at &gt;gmail.com&gt; wrote: We can have exact matches for all of these things: - the original thing that LLDB matches - the buggy GCC thing - the correct GCC thing Then we know exactly what we are matching and why. What I meant was more along the lines of “we could erroneously match other versions of std::vector&lt;&gt; that should not match”. I personally tend to avoid regexes unless you really need to match a broad and potentially unbounded range of types. In this case, it seems we have two or three different names, and it would also be good to track that one of these is just a workaround for a bug, rather than a real incarnation of the class. It is not critical because we do formatters caching (so we would look at the regexes once, figure out the match for vector&lt;bool&gt; and then reuse it until th</pre> Enrico Granata 2013-05-16T20:51:31 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1640 <pre> On May 16, 2013, at 1:09 PM, Michael Sartain &lt;mikesart&lt; at &gt;valvesoftware.com&gt; wrote: Again, this arch for the target comes from the main executable in the target. The main executable's arch is filled in from getting the process info right? So if we fix the process info so that the arch info is correct (it should return "x86_64-pc-linux" or whatever the llvm target triple is supposed to be for linux). Almost! There is "unknown unknown" (OS is unknown only because it wasn't specified), and "specified unknown" (we use this to mean "no OS")). My patch used this feature: if (!process_info.GetArchitecture().TripleVendorWasSpecified()) If you ask the ArchSpec::GetTriple().getOS(), it might return "llvm::Triple::UnknownOS". If the string was actually specified as "unknown", then "ArchSpec::GetTriple().getOSName()" will return a non-empty string containing "unknown". Another way to fix this would be to have a "llvm::Triple::NoOS" enumeration. There isn't one currently, so we currently test to se</pre> Greg Clayton 2013-05-16T20:28:01 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1639 <pre>This is fallout from changes over the years. If indeed ObjectFileELF creates its own data that is zero based, then the file offset should be ignored in other areas. It used to be each object file would lazily parse data from the file, but that led to crashes when someone would modify the file during a debug session. We would go to a file offset and read bytes that didn't make sense based off of the data we parsed when the first opened the file (like program and section headers). To fix this correctly, we now always mmap the entire object file when it first gets parsed so that we don't ever run into this case. During these changes, I switched all object file parsers over to always make their file data correct and zero based (go to file_offset, and read entire file up front). More answers below. On May 16, 2013, at 11:59 AM, Filipe Cabecinhas &lt;filcab&lt; at &gt;gmail.com&gt; wrote: It shouldn't if the m_data member is filled with the ELF file data starting at file_offset to begin with. Indeed, changes which happened </pre> Greg Clayton 2013-05-16T20:15:32 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1638 <pre>Hi Enrico, On 05/15/2013 11:32 PM, Enrico Granata wrote: Adding an exact string to match "std::vector&lt;bool, std::allocator&lt;bool&gt;, bool, std::allocator&lt;bool&gt; &gt;" would indeed serve as a workaround, but only for the specific case of vector&lt;bool&gt; + the GCC version with the bug + "frame variable". It will not be enough to match the "std::vector&lt;bool, std:allocator&lt;bool&gt; &gt;" that GCC initially intended to produce for "std::vector&lt;bool&gt;". It will not avoid problems with the erroneous parsing of other types that have templates parameters that will get duplicated. So I think the first patch was important to have a complete workaround. As I needed to match two similar types: "std::vector&lt;bool, std:allocator&lt;bool&gt; &gt;" (produced by GCC) and "std::vector&lt;std:allocator&lt;bool&gt; &gt;" (produced by Clang), I thought it was more appropriate to factor the two into the regex "^std::vector&lt;(bool,( )?)?std::allocator&lt;bool&gt; &gt;$". I removed it because it looked redundant, as it's already included in the regex summary for other vectors</pre> Yacine Belkadi 2013-05-16T20:13:40 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1637 <pre>Hi Greg, On 05/15/2013 11:08 PM, Greg Clayton wrote: I understand your concerns. I wasn't sure if a workaround was wanted in lldb. I attached one in case it was, and to have some code to discuss about. The patch is based on the assumption that a class or a function DIE shouldn't contain multiple identical template paramter DIEs. That template parameters DIEs should at least differ by name if everything else is identical. It looks reasonably safe to me, but I may be missing something. As I understand it, the choice is to avoid the workaround in lldb, and let GCC fix the problem. According to the GCC bug report, it's "Fixed for 4.8". So the test case will get from XFAIL to XPASS by itself, someday :) Yacine </pre> Yacine Belkadi 2013-05-16T20:13:20 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1636 <pre> Sorry I wasn't clear - this issue has nothing to do with the code in Linux/Host.cpp. It's showing up because we've now implemented ObjectFileELF::GetModuleSpecifications(). It's returning x86_64 / UnknownVendor / UnknownOS for this target I'm trying to debug where it used to return nothing. Ie, invalid arch. So in PlatformLinux.cpp, we are now running the exe_arch.IsValid() block down below (used to take the else clause). m_arch in module_spec is: Arch = llvm::Triple::x86_64, Vendor = llvm::Triple::UnknownVendor, OS = llvm::Triple::Linux, Environment = llvm::Triple::GNU exe_arch is: Arch = llvm::Triple::x86_64, Vendor = llvm::Triple::UnknownVendor, OS = llvm::Triple::UnknownOS, Environment = llvm::Triple::UnknownEnvironment ModuleList::GetShareModule() fails and reports my exe doesn't contain "x86_64". Modifying the code in ArchSpec to return Linux isn't the correct solution, but what is? Something local here where if OS is Unknown we match any OS? Thanks. if (erro</pre> Michael Sartain 2013-05-16T20:09:48 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1635 <pre>One thing I forgot to mention: the the modifications to ArchSpec.cpp should also be removed prior to submission. On May 16, 2013, at 11:50 AM, Greg Clayton &lt;gclayton&lt; at &gt;apple.com&gt; wrote: </pre> Greg Clayton 2013-05-16T20:00:23 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1634 <pre>Hi all, Why is ObjectFileELF using the file offset to parse the ELF headers? For the changes I'm suggesting, skip to the end of the message (3 last paragraphs). From what I can tell, ObjectFileELF's constructor will get a FileSpec+file_offset and a DataBuffer+data_offset. CreateInstance made sure the DataBuffer had all the data we needed. Then ObjectFileELF's constructor calls ObjectFile's constructor with those arguments too. ObjectFile's constructor sets its private m_data field to point to the argument DataBuffer's contents (+ offset), and simply stores the FileSpec and file_offset. When ObjectFileELF::ParseHeader() is called, it gets the file_offset and then parses the header from m_data with that offset. This makes no sense, for me, since the offset is only for the file, not the DataBuffer. I couldn't find any other reference to ObjectFile::GetFileOffset on either ObjectFile, ObjectFileELF, or ObjectFileMachO. There is one reference to m_file_offset in ObjectFileMachO, though. Which seems legit, b</pre> Filipe Cabecinhas 2013-05-16T18:59:55 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1633 <pre> On May 16, 2013, at 11:32 AM, Michael Sartain &lt;mikesart&lt; at &gt;valvesoftware.com&gt; wrote: No, I would do this by modifying all the architectures in ModuleSpec objects that are returned from ObjectFile::GetModuleSpecifications() inside GetELFProcessCPUType(). All we know by looking at an ELF file and grabbing its specifications is that is has an architecture, we don't know what OS the ELF file is destined for. But in GetELFProcessCPUType(), which might be better named GetProcessCPUTypeFromExecutable() since it isn't ELF specific, we know we have an executable file for the current host. So I would make your function now with something like: static bool GetProcessCPUTypeFromExecutable (const char *exe_path, ProcessInstanceInfo &amp;process_info) { // Clear the architecture. process_info.GetArchitecture().Clear(); ModuleSpecList specs; FileSpec filespec (exe_path, false); const size_t num_specs = ObjectFile::GetModuleSpecifications (filespec, 0, specs); assert(num_specs == 1 &amp;&amp; "Linux plugin su</pre> Greg Clayton 2013-05-16T18:50:00 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1632 <pre> Yeah, that makes me feel more comfortable with that "== 1" check. It's in. I ran into an issue where TargetList::CreateTarget() was failing because it's calling ObjectFile::GetModuleSpecifications() and getting back x86_64 / UnknownVendor / UnknownOS and is expecting to find the Linux for the OS when it calls IsCompatibleMatch(). So I modified ArchSpec::SetArchitecture() to set the Linux OS using an ifdef in ArchSpec.cpp. Is this the best way to do this? I also got rid of the llvm::Triple::PC for vendor. This just seemed wrong as Linux can run on all kinds of platforms. I did write some code to get the distributor name from /etc/lsb-release, but the llvm triple doesn't line up with anything there of course. So for now it spits out "x86_64-unknown-linux". The final patch is down below. Let me know if this is all ok and I'll submit. Thanks again for all the help / feedback on everything. -Mike Index: source/Host/linux/Host.cpp =================================================================== --- sou</pre> Michael Sartain 2013-05-16T18:32:29 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1631 <pre>http://llvm.org/bugs/show_bug.cgi?id=14806 Daniel Malea &lt;daniel.malea&lt; at &gt;intel.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Daniel Malea &lt;daniel.malea&lt; at &gt;intel.com&gt; --- "platform status" command now shows equivalent information as on Mac OS X as of r182030; thanks for the patch Matthew! </pre> bugzilla-daemon< at >llvm.org 2013-05-16T17:56:10 http://permalink.gmane.org/gmane.comp.debugging.lldb.devel/1630 <pre>Hi Matthew, welcome to LLDB! I tried it out, and it looked good, so I committed in r182030. Keep the fixes coming :) Dan From: Matthew Sorrels &lt;sorrels.m&lt; at &gt;gmail.com&lt;mailto:sorrels.m&lt; at &gt;gmail.com&gt;&gt; Date: Wednesday, 15 May, 2013 8:01 PM To: "lldb-dev&lt; at &gt;cs.uiuc.edu&lt;mailto:lldb-dev&lt; at &gt;cs.uiuc.edu&gt;" &lt;lldb-dev&lt; at &gt;cs.uiuc.edu&lt;mailto:lldb-dev&lt; at &gt;cs.uiuc.edu&gt;&gt; Subject: [lldb-dev] PATCH for REVIEW: Fix [Bug 14806] platform status command prints less information on Linux than on Mac OS X I've expanded PlatformLinux::GetStatus to work more like the Mac version (by calling Platform::GetStatus and then adding in the fields from uname in the same format). I've also fixed the test case for this to no longer expect failure. Here's the new output: (lldb) platform status Platform: host Triple: x86_64--linux-gnu OS Version: 3.2.0 Hostname: localhost Kernel: Linux Release: 3.2.0-41-generic Version: #66-Ubuntu SMP Thu Apr 25 03:27:11 UTC 2013 Index: test/functionalities/platform/TestPlatformCommand.py ===============</pre> Malea, Daniel 2013-05-16T17:55:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.debugging.lldb.devel