Re: [Lldb-commits] [lldb] r258113 - Unconditionally accept symbol sizes from elf
Sorry for breaking the windows tests. I don't have a windows box to investigate it but based on your description the regression is caused by my CL while I believe the bug is in ObjectFilePECOFF (is it the one used on Windows?). The problem is that you have symbols with m_byte_size == 0 while calling Symtab::FindSymbolContainingFileAddress what is invalid in almost every case. Most likely it is caused by an issue in ObjectFilePECOFF::GetSymtab where you don't set the size of the symbols. You either have to specify the size of each symbol with calling Symbol::SetByteSize if this information is stored in the the object file (done in case of elf) or call Symtab::CalculateSymbolSizes (done in case of mach-o) after you parsed all symbols (what will set the size of each symbol with 0 size to last until the next symbol). Can you try out is doing one of these fixes your issue? Thanks, Tamas On Wed, Jan 20, 2016 at 11:19 PM Adrian McCarthy wrote: > In `Symtab::FindSymbolContainingFileAddress`, the address range for the > symbols we're finding always have `m_byte_size == 0`, so the extra check > `symbol->ContainsFileAddress(file_addr)` always fails, causing us to return > nullptr instead of the symbol. > > I don't know if that's the right behavior, but that is the change that's > causing thread `step-over` to fail on Windows, which takes out about a > dozen tests. > > > > On Wed, Jan 20, 2016 at 2:33 PM, Zachary Turner via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > >> Hi Tamas, >> >> I think this build breaks Windows. This is actually the breakage that we >> were discussing in the thread about thread step-over. >> >> 1 revision before your patch: >> D:\src\llvmbuild\ninja>C:\Python35\python_d.exe >> D:/src/llvm/tools/lldb/test/dotest.py -q --arch=i686 --executable >> D:/src/llvmbuild/ninja/bin/lldb.exe -s >> D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS >> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe -p >> TestSignedTypes.py D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test >> --no-multiprocess >> LLDB library dir: D:/src/llvmbuild/ninja/bin >> LLDB import library dir: D:/src/llvmbuild/ninja/bin\..\lib >> lldb version 3.9.0 clang revision 257802 llvm revision 257804 >> The 'lldb-mi' executable cannot be located. The lldb-mi tests can not be >> run as a result. >> >> Session logs for test failures/errors/unexpected successes will go into >> directory 'D:/src/llvmbuild/ninja/lldb-test-traces' >> Command invoked: D:/src/llvm/tools/lldb/test/dotest.py -q --arch=i686 >> --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s >> D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS >> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe -p >> TestSignedTypes.py D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test >> --no-multiprocess >> PASS: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: >> test_dwarf (TestSignedTypes.UnsignedTypesTestCase) >> -- >> Ran 1 test in 1.820s >> >> RESULT: PASSED (1 passes, 0 failures, 0 errors, 0 skipped, 0 expected >> failures, 0 unexpected successes) >> >> With your patch: >> D:\src\llvmbuild\ninja>C:\Python35\python_d.exe >> D:/src/llvm/tools/lldb/test/dotest.py -q --arch=i686 --executable >> D:/src/llvmbuild/ninja/bin/lldb.exe -s >> D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS >> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe -p >> TestSignedTypes.py D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test >> --no-multiprocess >> LLDB library dir: D:/src/llvmbuild/ninja/bin >> LLDB import library dir: D:/src/llvmbuild/ninja/bin\..\lib >> lldb version 3.9.0 clang revision 257802 llvm revision 257804 >> The 'lldb-mi' executable cannot be located. The lldb-mi tests can not be >> run as a result. >> >> Session logs for test failures/errors/unexpected successes will go into >> directory 'D:/src/llvmbuild/ninja/lldb-test-traces' >> Command invoked: D:/src/llvm/tools/lldb/test/dotest.py -q --arch=i686 >> --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s >> D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS >> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe -p >> TestSignedTypes.py D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test >> --no-multiprocess >> FAIL: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: >> test_dwarf (TestSignedTypes.UnsignedTypesTestCase) >> == >> FAIL: test_dwarf (TestSignedTypes.UnsignedTypesTestCase) >>Test that variables with signed types display correctly. >> -- >> Traceback (most recent call last): >> File >> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line >> 2249, in dwarf_test_method >> return attrvalue(self) >> File >> "D:\src\llvm\tools\lldb\pa
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
tberghammer added a comment. In http://reviews.llvm.org/D16334#331428, @zturner wrote: > In http://reviews.llvm.org/D16334#331420, @tberghammer wrote: > > > In http://reviews.llvm.org/D16334#331368, @zturner wrote: > > > > > I don't know, I still disagree. If something in step-over breaks, I > > > dont' want to dig through a list of 30 other tests that have nothing to > > > do with the problem, only to find out 2 days later that the problem is > > > actually in step over. The only reason this helps is because the test > > > suite is insufficient as it is. But it doesn't need to be! > > > > > > I agree but first we should fix the test coverage and then fix the > > individual tests. Doing it in the opposite way will cause a significant > > drop in quality (we will fix individual tests but not increase the coverage > > enough). > > > > > The real solution is for people to start thinking about tests more. I've > > > hounded on this time and time again, but it seems most of the time tests > > > only get added when I catch a CL go by with no tests and request them. > > > Sometimes they don't even get added then. "Oh yea this is on my radar, > > > I'll loop back around to it." . Hundreds of CLs > > > have gone in over the past few months, and probably 10 tests have gone > > > in. *That's* the problem. People should be spending as much time > > > thinking about how to write tests as they are about how to write the > > > thing they're implementing. Almost every CL can be tested. Everything, > > > no matter how small, can be tested. If the SB tests are too heavyweight, > > > that's what the unit tests are for. IF there's no SB API that does what > > > you need to do to test it, add the SB API. "But I have to design the API > > > first" is not an excuse. Design it then. > > > > > > I think we need a different API for tests then the SB API which can be > > changed more freely without have to worry about backward compatibility. > > When adding a new feature I try to avoid adding an SB API until I know for > > sure what data I have to expose because a wrong decision early on will > > carry forward (how many deprecated SB API calls we have?). > > > Do you have a concrete example of where you don't want to add an SB API, but > a unit test isn't ideal? Recently we added several language specific commands for render script and for go. I don't think we want to add SB API support for these at the moment because nobody uses them so maintaining it could be problematic. In http://reviews.llvm.org/D16334#331429, @zturner wrote: > In http://reviews.llvm.org/D16334#331420, @tberghammer wrote: > > > It is true that every CL can be tested but a lot of change is going in to > > address a specific edge case generated by a specific compiler in a strange > > situation. To create a reliable test from it we have to commit in a > > compiled binary with the strange/incorrect debug info and then it will be a > > platform and architecture specific test what is also very hard to debug > > because you most likely can't recompile it with your own compiler. I am not > > sure we want to go down in this road. > > > You can test cases like this easily with unit tests and dependency injection. > Just make a mock interface that returns the exact values you need when > queried for certain symbols or whatever. To do this we have to mock a lot of thing including the full Process and Thread classes what I am not too fancy doing because I expect that a completely unrelated change will break the mock. Personally I am more happy to debug a complicated test then to maintain a huge number of tests but I know that lot of people have different preferences. Also I prefer using stress tests and fuzzing instead of trying to create a specific test for each edge case we can think about because it keeps the number of tests low and relatively easy to maintain with having a high probability of detecting issues. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16293: [cmake] Make dependencies of lldb libraries private
labath updated this revision to Diff 45529.
labath added a comment.
Use private keyword for linux only
http://reviews.llvm.org/D16293
Files:
cmake/modules/AddLLDB.cmake
tools/argdumper/CMakeLists.txt
Index: tools/argdumper/CMakeLists.txt
===
--- tools/argdumper/CMakeLists.txt
+++ tools/argdumper/CMakeLists.txt
@@ -1,8 +1,16 @@
+include(${LLDB_PROJECT_ROOT}/cmake/LLDBDependencies.cmake)
+
add_lldb_executable(lldb-argdumper
argdumper.cpp
)
-target_link_libraries(lldb-argdumper liblldb)
+if (LLDB_LINKER_SUPPORTS_GROUPS)
+ target_link_libraries(lldb-argdumper -Wl,--start-group ${LLDB_USED_LIBS}
-Wl,--end-group)
+else()
+ target_link_libraries(lldb-argdumper ${LLDB_USED_LIBS})
+endif()
+llvm_config(lldb-argdumper ${LLVM_LINK_COMPONENTS})
+
install(TARGETS lldb-argdumper
RUNTIME DESTINATION bin)
Index: cmake/modules/AddLLDB.cmake
===
--- cmake/modules/AddLLDB.cmake
+++ cmake/modules/AddLLDB.cmake
@@ -4,7 +4,11 @@
endif()
if(${targetkind} MATCHES "SHARED")
-set(LINK_KEYWORD ${cmake_2_8_12_PUBLIC})
+if(CMAKE_SYSTEM_NAME MATCHES "Linux")
+ set(LINK_KEYWORD ${cmake_2_8_12_PRIVATE})
+else()
+ set(LINK_KEYWORD ${cmake_2_8_12_PUBLIC})
+endif()
endif()
if(${targetkind} MATCHES "SHARED" OR ${targetkind} MATCHES "EXE")
@@ -62,10 +66,10 @@
if (PARAM_SHARED)
if (LLDB_LINKER_SUPPORTS_GROUPS)
-target_link_libraries(${name} ${cmake_2_8_12_PUBLIC}
+target_link_libraries(${name} ${cmake_2_8_12_PRIVATE}
-Wl,--start-group ${CLANG_USED_LIBS} -Wl,--end-group)
else()
-target_link_libraries(${name} ${cmake_2_8_12_PUBLIC}
${CLANG_USED_LIBS})
+target_link_libraries(${name} ${cmake_2_8_12_PRIVATE}
${CLANG_USED_LIBS})
endif()
endif()
llvm_config(${name} ${LLVM_LINK_COMPONENTS})
Index: tools/argdumper/CMakeLists.txt
===
--- tools/argdumper/CMakeLists.txt
+++ tools/argdumper/CMakeLists.txt
@@ -1,8 +1,16 @@
+include(${LLDB_PROJECT_ROOT}/cmake/LLDBDependencies.cmake)
+
add_lldb_executable(lldb-argdumper
argdumper.cpp
)
-target_link_libraries(lldb-argdumper liblldb)
+if (LLDB_LINKER_SUPPORTS_GROUPS)
+ target_link_libraries(lldb-argdumper -Wl,--start-group ${LLDB_USED_LIBS} -Wl,--end-group)
+else()
+ target_link_libraries(lldb-argdumper ${LLDB_USED_LIBS})
+endif()
+llvm_config(lldb-argdumper ${LLVM_LINK_COMPONENTS})
+
install(TARGETS lldb-argdumper
RUNTIME DESTINATION bin)
Index: cmake/modules/AddLLDB.cmake
===
--- cmake/modules/AddLLDB.cmake
+++ cmake/modules/AddLLDB.cmake
@@ -4,7 +4,11 @@
endif()
if(${targetkind} MATCHES "SHARED")
-set(LINK_KEYWORD ${cmake_2_8_12_PUBLIC})
+if(CMAKE_SYSTEM_NAME MATCHES "Linux")
+ set(LINK_KEYWORD ${cmake_2_8_12_PRIVATE})
+else()
+ set(LINK_KEYWORD ${cmake_2_8_12_PUBLIC})
+endif()
endif()
if(${targetkind} MATCHES "SHARED" OR ${targetkind} MATCHES "EXE")
@@ -62,10 +66,10 @@
if (PARAM_SHARED)
if (LLDB_LINKER_SUPPORTS_GROUPS)
-target_link_libraries(${name} ${cmake_2_8_12_PUBLIC}
+target_link_libraries(${name} ${cmake_2_8_12_PRIVATE}
-Wl,--start-group ${CLANG_USED_LIBS} -Wl,--end-group)
else()
-target_link_libraries(${name} ${cmake_2_8_12_PUBLIC} ${CLANG_USED_LIBS})
+target_link_libraries(${name} ${cmake_2_8_12_PRIVATE} ${CLANG_USED_LIBS})
endif()
endif()
llvm_config(${name} ${LLVM_LINK_COMPONENTS})
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16293: [cmake] Make dependencies of lldb libraries private
labath added a comment. I think a similar command as for argdumper would fix this (probably `target_link_libraries(lldb, lldbHost)`). I thought about doing that instead, but then I realised that netbsd probably needs this as well, and lldb-mi seems to be using getopt also, etc. So I figured I'll make this as surgical as possible, and enable the fix on linux only. When this gets into 3.8, I will add a separate patch, which sets the private keyword everywhere, getopt (through lldbHost) to lldb and lldb-mi on relevant platforms. How does that sound? http://reviews.llvm.org/D16293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16322: Enable test log collection from remote debug servers
labath added a comment. Any thoughts? Objections? Indifference? :) http://reviews.llvm.org/D16322 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16322: Enable test log collection from remote debug servers
tfiala added a comment. Oops, this one slipped past me. Looking now! http://reviews.llvm.org/D16322 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16322: Enable test log collection from remote debug servers
tfiala accepted this revision.
tfiala added a comment.
This revision is now accepted and ready to land.
Looks reasonable.
I added one question on whether we can get a warning on failure to retrieve the
server.log file when expecting one and it doesn't show up (perhaps only in
verbose mode), which is totally not needed for this patch.
There's also one minor comment fix.
Comment at: packages/Python/lldbsuite/test/lldbtest.py:1380
@@ +1379,3 @@
+# Retrieve the server log (if any) from the remote system. It is
assumed the server log
+# is writting to the "server.log" file in the current test directory.
This can be
+# achieved by setting LLDB_DEBUGSERVER_LOG_FILE="server.log" when
starting remote
minor: s/writting/writing/
Comment at: packages/Python/lldbsuite/test/lldbtest.py:1385-1386
@@ +1384,4 @@
+# This is executed on a best-effort basis. If the file is not
there, so be it.
+lldb.remote_platform.Get(lldb.SBFileSpec("server.log"),
+
lldb.SBFileSpec(self.getLogBasenameForCurrentTest()+"-server.log"))
+
It might be nice to get some kind of output (perhaps in verbose mode?) if we're
expecting the server.log to be there but we fail to retrieve it. (Just a
warning). Does lldb.remote_platform.Get() already do that on a failure?
http://reviews.llvm.org/D16322
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15318: Get rid of global variables in dotest.py
tfiala added a comment. Can this be closed out? http://reviews.llvm.org/D15318 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15162: Have result formatter send bytes instead of strings
tfiala added a comment. Is this ready to close out? http://reviews.llvm.org/D15162 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14885: Create lldbsuite.support.fs and move `find_executable` there
tfiala added a comment. Can this be closed out? http://reviews.llvm.org/D14885 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14896: Local path implementation of swig-bot.py
tfiala added a comment. Can this be closed out? http://reviews.llvm.org/D14896 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14937: swig_bot remote path preliminary implementation
tfiala added a comment. Ready to close out? http://reviews.llvm.org/D14937 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15209: Fix script import --allow-reload on Python 3
tfiala added a comment. Can this be closed out? http://reviews.llvm.org/D15209 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16322: Enable test log collection from remote debug servers
labath added inline comments.
Comment at: packages/Python/lldbsuite/test/lldbtest.py:1385-1386
@@ +1384,4 @@
+# This is executed on a best-effort basis. If the file is not
there, so be it.
+lldb.remote_platform.Get(lldb.SBFileSpec("server.log"),
+
lldb.SBFileSpec(self.getLogBasenameForCurrentTest()+"-server.log"))
+
tfiala wrote:
> It might be nice to get some kind of output (perhaps in verbose mode?) if
> we're expecting the server.log to be there but we fail to retrieve it. (Just
> a warning). Does lldb.remote_platform.Get() already do that on a failure?
It's not really clear when are we expecting it. A user might choose to enable
logging on the remote system, or he may choose not to. Both are valid options,
and right now we don't tell the client which one of them is happening. So,
unless we introduce another option `--enable-server-logging` or something, the
client has no way of knowing whether server logging is active.
Perhaps I could just rephrase the comment to better explain the "best-effort"
part?
http://reviews.llvm.org/D16322
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16322: Enable test log collection from remote debug servers
tfiala added inline comments.
Comment at: packages/Python/lldbsuite/test/lldbtest.py:1385-1386
@@ +1384,4 @@
+# This is executed on a best-effort basis. If the file is not
there, so be it.
+lldb.remote_platform.Get(lldb.SBFileSpec("server.log"),
+
lldb.SBFileSpec(self.getLogBasenameForCurrentTest()+"-server.log"))
+
labath wrote:
> tfiala wrote:
> > It might be nice to get some kind of output (perhaps in verbose mode?) if
> > we're expecting the server.log to be there but we fail to retrieve it.
> > (Just a warning). Does lldb.remote_platform.Get() already do that on a
> > failure?
> It's not really clear when are we expecting it. A user might choose to enable
> logging on the remote system, or he may choose not to. Both are valid
> options, and right now we don't tell the client which one of them is
> happening. So, unless we introduce another option `--enable-server-logging`
> or something, the client has no way of knowing whether server logging is
> active.
>
> Perhaps I could just rephrase the comment to better explain the "best-effort"
> part?
Oh okay - I thought we'd know for sure if the user was trying (or not trying)
to log on the remote system. If we don't know, no biggie. I just thought it
would be nice to know we didn't get the log when we were expecting it. But if
that's not possible, so be it.
http://reviews.llvm.org/D16322
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15209: Fix script import --allow-reload on Python 3
granata.enrico accepted this revision. granata.enrico added a comment. Yes, I believe so. http://reviews.llvm.org/D15209 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D16412: remove unused local string in IRForTarget.cpp
ldrumm created this revision.
ldrumm added reviewers: spyffe, jingham.
ldrumm added a subscriber: lldb-commits.
It looks like there's an unused variable in
`source/Plugins/Expression/Clang/IRForTarget.cpp` `std::string name` is
assigned the function name, then never used again.
;
There don't appear to be any side-effects from removing this.
http://reviews.llvm.org/D16412
Files:
source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
Index: source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
===
--- source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
+++ source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
@@ -163,8 +163,6 @@
{
llvm_function.setLinkage(GlobalValue::ExternalLinkage);
-std::string name = llvm_function.getName().str();
-
return true;
}
Index: source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
===
--- source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
+++ source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
@@ -163,8 +163,6 @@
{
llvm_function.setLinkage(GlobalValue::ExternalLinkage);
-std::string name = llvm_function.getName().str();
-
return true;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14111: Use "_$" prefix instead of "$" for dynamic checker function inserted by LLDB during expression evaluation
spyffe accepted this revision. spyffe added a comment. This revision is now accepted and ready to land. Thank you for that clarification. In that case, I think this patch is fine as it is. Repository: rL LLVM http://reviews.llvm.org/D14111 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258414 - Enable test log collection from remote debug servers
Author: labath
Date: Thu Jan 21 11:54:14 2016
New Revision: 258414
URL: http://llvm.org/viewvc/llvm-project?rev=258414&view=rev
Log:
Enable test log collection from remote debug servers
Summary:
We already have the ability to collect the server logs when doing local
debugging. This enables
the collection of remote logs as well. This relies on specifying a relative
path "server.log" for
LLDB_DEBUGSERVER_LOG_FILE when starting remote platform. Since we always set
the platform working
directory to a fresh folder to avoid conflicts, the actual file path will
always be different and
we can pick the logs up from there.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16322
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=258414&r1=258413&r2=258414&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Thu Jan 21 11:54:14
2016
@@ -1345,7 +1345,7 @@ class Base(unittest2.TestCase):
else:
categories = "default"
-if channel == "gdb-remote":
+if channel == "gdb-remote" and lldb.remote_platform is None:
# communicate gdb-remote categories to debugserver
os.environ["LLDB_DEBUGSERVER_LOG_FLAGS"] = categories
@@ -1354,12 +1354,15 @@ class Base(unittest2.TestCase):
raise Exception('log enable failed (check LLDB_LOG_OPTION env
variable)')
# Communicate log path name to debugserver & lldb-server
-server_log_path = "{}-server.log".format(log_basename)
-open(server_log_path, 'w').close()
-os.environ["LLDB_DEBUGSERVER_LOG_FILE"] = server_log_path
+# For remote debugging, these variables need to be set when starting
the platform
+# instance.
+if lldb.remote_platform is None:
+server_log_path = "{}-server.log".format(log_basename)
+open(server_log_path, 'w').close()
+os.environ["LLDB_DEBUGSERVER_LOG_FILE"] = server_log_path
-# Communicate channels to lldb-server
-os.environ["LLDB_SERVER_LOG_CHANNELS"] =
":".join(lldbtest_config.channels)
+# Communicate channels to lldb-server
+os.environ["LLDB_SERVER_LOG_CHANNELS"] =
":".join(lldbtest_config.channels)
if len(lldbtest_config.channels) == 0:
return
@@ -1373,6 +1376,15 @@ class Base(unittest2.TestCase):
if not self.res.Succeeded():
raise Exception('log disable failed (check LLDB_LOG_OPTION env
variable)')
+# Retrieve the server log (if any) from the remote system. It is
assumed the server log
+# is writing to the "server.log" file in the current test directory.
This can be
+# achieved by setting LLDB_DEBUGSERVER_LOG_FILE="server.log" when
starting remote
+# platform. If the remote logging is not enabled, then just let the
Get() command silently
+# fail.
+if lldb.remote_platform:
+lldb.remote_platform.Get(lldb.SBFileSpec("server.log"),
+
lldb.SBFileSpec(self.getLogBasenameForCurrentTest()+"-server.log"))
+
def setUp(self):
"""Fixture for unittest test case setup.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16322: Enable test log collection from remote debug servers
This revision was automatically updated to reflect the committed changes.
Closed by commit rL258414: Enable test log collection from remote debug servers
(authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D16322?vs=45273&id=45553#toc
Repository:
rL LLVM
http://reviews.llvm.org/D16322
Files:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
Index: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
@@ -1345,21 +1345,24 @@
else:
categories = "default"
-if channel == "gdb-remote":
+if channel == "gdb-remote" and lldb.remote_platform is None:
# communicate gdb-remote categories to debugserver
os.environ["LLDB_DEBUGSERVER_LOG_FLAGS"] = categories
self.ci.HandleCommand(log_enable + channel_with_categories,
self.res)
if not self.res.Succeeded():
raise Exception('log enable failed (check LLDB_LOG_OPTION env
variable)')
# Communicate log path name to debugserver & lldb-server
-server_log_path = "{}-server.log".format(log_basename)
-open(server_log_path, 'w').close()
-os.environ["LLDB_DEBUGSERVER_LOG_FILE"] = server_log_path
+# For remote debugging, these variables need to be set when starting
the platform
+# instance.
+if lldb.remote_platform is None:
+server_log_path = "{}-server.log".format(log_basename)
+open(server_log_path, 'w').close()
+os.environ["LLDB_DEBUGSERVER_LOG_FILE"] = server_log_path
-# Communicate channels to lldb-server
-os.environ["LLDB_SERVER_LOG_CHANNELS"] =
":".join(lldbtest_config.channels)
+# Communicate channels to lldb-server
+os.environ["LLDB_SERVER_LOG_CHANNELS"] =
":".join(lldbtest_config.channels)
if len(lldbtest_config.channels) == 0:
return
@@ -1373,6 +1376,15 @@
if not self.res.Succeeded():
raise Exception('log disable failed (check LLDB_LOG_OPTION env
variable)')
+# Retrieve the server log (if any) from the remote system. It is
assumed the server log
+# is writing to the "server.log" file in the current test directory.
This can be
+# achieved by setting LLDB_DEBUGSERVER_LOG_FILE="server.log" when
starting remote
+# platform. If the remote logging is not enabled, then just let the
Get() command silently
+# fail.
+if lldb.remote_platform:
+lldb.remote_platform.Get(lldb.SBFileSpec("server.log"),
+
lldb.SBFileSpec(self.getLogBasenameForCurrentTest()+"-server.log"))
+
def setUp(self):
"""Fixture for unittest test case setup.
Index: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
@@ -1345,21 +1345,24 @@
else:
categories = "default"
-if channel == "gdb-remote":
+if channel == "gdb-remote" and lldb.remote_platform is None:
# communicate gdb-remote categories to debugserver
os.environ["LLDB_DEBUGSERVER_LOG_FLAGS"] = categories
self.ci.HandleCommand(log_enable + channel_with_categories, self.res)
if not self.res.Succeeded():
raise Exception('log enable failed (check LLDB_LOG_OPTION env variable)')
# Communicate log path name to debugserver & lldb-server
-server_log_path = "{}-server.log".format(log_basename)
-open(server_log_path, 'w').close()
-os.environ["LLDB_DEBUGSERVER_LOG_FILE"] = server_log_path
+# For remote debugging, these variables need to be set when starting the platform
+# instance.
+if lldb.remote_platform is None:
+server_log_path = "{}-server.log".format(log_basename)
+open(server_log_path, 'w').close()
+os.environ["LLDB_DEBUGSERVER_LOG_FILE"] = server_log_path
-# Communicate channels to lldb-server
-os.environ["LLDB_SERVER_LOG_CHANNELS"] = ":".join(lldbtest_config.channels)
+# Communicate channels to lldb-server
+os.environ["LLDB_SERVER_LOG_CHANNELS"] = ":".join(lldbtest_config.channels)
if len(lldbtest_config.channels) == 0:
return
@@ -1373,6 +1376,15 @@
if not self.res.Succeeded():
raise Exception('log disable failed (check LLDB_LOG_OPTION env variable)')
+# Retrieve the server log (if any) from the remote system. It is assumed the server log
+# is writing to the "server.log" file in the current test dir
Re: [Lldb-commits] [PATCH] D16293: [cmake] Make dependencies of lldb libraries private
zturner added a comment. Unfortunately that's not going to work. Because lldb libraries are not layered very well, linking against any one library is going to cause a transitive link dependency on every other library. I did a lot of work to improve that in order to get the Python stuff separated out, but it's still not in a great state. So right now, there's no way to just link against host, because that's the same as linking against everything http://reviews.llvm.org/D16293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. Sure, an interface change to Process might break the mock, but it would break at compile time, you just fix it up. It's not something that would happen frequently, this is the same situation going on in LLVM where there are unit tests, sometimes they break, and people fix them. But it's never been an issue because it doesn't happen often. I know there are different opinions about what type of tests to write and how reduced they should be, but in this case I'm simply following the LLVM guidelines for writing test cases, which we supposed to adhere to. http://llvm.org/docs/DeveloperPolicy.html#test-cases (except for obvious differences about how it uses lit, etc) http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D16415: Call CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab
amccarth created this revision. amccarth added reviewers: tberghammer, zturner. amccarth added a subscriber: lldb-commits. This fixes the nine tests that regressed on Windows after http://reviews.llvm.org/D16186 http://reviews.llvm.org/D16415 Files: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp === --- source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp +++ source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp @@ -649,6 +649,7 @@ symbols[i].SetDebug(true); } } +m_symtab_ap->CalculateSymbolSizes(); } } return m_symtab_ap.get(); Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp === --- source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp +++ source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp @@ -649,6 +649,7 @@ symbols[i].SetDebug(true); } } +m_symtab_ap->CalculateSymbolSizes(); } } return m_symtab_ap.get(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16415: Call CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab
zturner added a reviewer: clayborg. zturner added a comment. looks fine to me, but some Apple targets use PE, so +greg in case he can think of a reason why this will mess up something on the Apple side. http://reviews.llvm.org/D16415 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16415: Call CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab
tberghammer added a comment. Looks good to me and if Apple using this code then I am pretty sure my CL break them as well. Having 0 size symbols around will cause a lot of issue around LLDB. http://reviews.llvm.org/D16415 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
> On Jan 21, 2016, at 10:17 AM, Zachary Turner wrote: > > zturner added a comment. > > Sure, an interface change to Process might break the mock, but it would break > at compile time, you just fix it up. It's not something that would happen > frequently, this is the same situation going on in LLVM where there are unit > tests, sometimes they break, and people fix them. But it's never been an > issue because it doesn't happen often. > > I know there are different opinions about what type of tests to write and how > reduced they should be, but in this case I'm simply following the LLVM > guidelines for writing test cases, which we supposed to adhere to. > http://llvm.org/docs/DeveloperPolicy.html#test-cases (except for obvious > differences about how it uses lit, etc) I do not think that we should be restricted to guidelines for testing that are meant for a very different kind of program. You don't stop a compiler midway through a compile, drop into the "compiler command line", add a few more lines of code and a couple of functions, change some compiler options and continue. You give it input, and collect the output or errors. But you do the functionally equivalent thing in the debugger all the time. So the way you test things is going to be very different. Jim > > > http://reviews.llvm.org/D16334 > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D16423: test suite: fix exception if --platform-name is specified that doesn't start with "remote-"
tfiala created this revision.
tfiala added a reviewer: labath.
tfiala added a subscriber: lldb-commits.
As would happen if the test suite was given "--platform-name iso-simulator".
Also removes the expected timeouts for Darwin as these are now handled by
reruns.
http://reviews.llvm.org/D16423
Files:
packages/Python/lldbsuite/test/dosep.py
Index: packages/Python/lldbsuite/test/dosep.py
===
--- packages/Python/lldbsuite/test/dosep.py
+++ packages/Python/lldbsuite/test/dosep.py
@@ -1135,29 +1135,24 @@
def getExpectedTimeouts(platform_name):
# returns a set of test filenames that might timeout
# are we running against a remote target?
-host = sys.platform
if platform_name is None:
target = sys.platform
else:
m = re.search(r'remote-(\w+)', platform_name)
-target = m.group(1)
+if m:
+target = m.group(1)
+else:
+target = None
expected_timeout = set()
-if target.startswith("freebsd"):
+if target is not None and target.startswith("freebsd"):
expected_timeout |= {
"TestBreakpointConditions.py",
"TestChangeProcessGroup.py",
"TestValueObjectRecursion.py",
"TestWatchpointConditionAPI.py",
}
-elif target.startswith("darwin"):
-expected_timeout |= {
-# times out on MBP Retina, Mid 2012
-"TestThreadSpecificBreakpoint.py",
-"TestExitDuringStep.py",
-"TestIntegerTypesExpr.py",
-}
return expected_timeout
Index: packages/Python/lldbsuite/test/dosep.py
===
--- packages/Python/lldbsuite/test/dosep.py
+++ packages/Python/lldbsuite/test/dosep.py
@@ -1135,29 +1135,24 @@
def getExpectedTimeouts(platform_name):
# returns a set of test filenames that might timeout
# are we running against a remote target?
-host = sys.platform
if platform_name is None:
target = sys.platform
else:
m = re.search(r'remote-(\w+)', platform_name)
-target = m.group(1)
+if m:
+target = m.group(1)
+else:
+target = None
expected_timeout = set()
-if target.startswith("freebsd"):
+if target is not None and target.startswith("freebsd"):
expected_timeout |= {
"TestBreakpointConditions.py",
"TestChangeProcessGroup.py",
"TestValueObjectRecursion.py",
"TestWatchpointConditionAPI.py",
}
-elif target.startswith("darwin"):
-expected_timeout |= {
-# times out on MBP Retina, Mid 2012
-"TestThreadSpecificBreakpoint.py",
-"TestExitDuringStep.py",
-"TestIntegerTypesExpr.py",
-}
return expected_timeout
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
Right, but I don't agree in this case that "different" has to mean "we discourage the use of reduced test cases". I have a hard time imagining a scenario where not having reduced test cases is an advantage. It's also easy to explain to people. "Write reduced test cases". It's easy to understand. Moreso than "Reduced test cases are good, but not always because fuzziness, but we can't really put into words exactly what amount of fuzziness we want, or what it should look like, so I guess anything goes - don't ask don't tell". If we want fuzziness, we should do fuzz testing. Feature tests and regression tests should be reduced. The whole reason the tests in lldb/tests were written is because people were testing a specific feature or bugfix. I don't see a reason to add fuzziness to this kind of test. All it does is pollute failure logs. Fuzziness is better tested by fuzz tests. On Thu, Jan 21, 2016 at 11:46 AM Jim Ingham wrote: > > > On Jan 21, 2016, at 10:17 AM, Zachary Turner wrote: > > > > zturner added a comment. > > > > Sure, an interface change to Process might break the mock, but it would > break at compile time, you just fix it up. It's not something that would > happen frequently, this is the same situation going on in LLVM where there > are unit tests, sometimes they break, and people fix them. But it's never > been an issue because it doesn't happen often. > > > > I know there are different opinions about what type of tests to write > and how reduced they should be, but in this case I'm simply following the > LLVM guidelines for writing test cases, which we supposed to adhere to. > http://llvm.org/docs/DeveloperPolicy.html#test-cases (except for obvious > differences about how it uses lit, etc) > > I do not think that we should be restricted to guidelines for testing that > are meant for a very different kind of program. You don't stop a compiler > midway through a compile, drop into the "compiler command line", add a few > more lines of code and a couple of functions, change some compiler options > and continue. You give it input, and collect the output or errors. But > you do the functionally equivalent thing in the debugger all the time. So > the way you test things is going to be very different. > > Jim > > > > > > > > http://reviews.llvm.org/D16334 > > > > > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. Right, but I don't agree in this case that "different" has to mean "we discourage the use of reduced test cases". I have a hard time imagining a scenario where not having reduced test cases is an advantage. It's also easy to explain to people. "Write reduced test cases". It's easy to understand. Moreso than "Reduced test cases are good, but not always because fuzziness, but we can't really put into words exactly what amount of fuzziness we want, or what it should look like, so I guess anything goes - don't ask don't tell". If we want fuzziness, we should do fuzz testing. Feature tests and regression tests should be reduced. The whole reason the tests in lldb/tests were written is because people were testing a specific feature or bugfix. I don't see a reason to add fuzziness to this kind of test. All it does is pollute failure logs. Fuzziness is better tested by fuzz tests. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
I'm not sure this is a terribly productive discussion. Since I know that the debugger is stateful, when I write a test where I get to point A and do thing X, I will often add - while I'm there - "step again and see if it still works" or something morally equivalent to that. I have found that to be a method of test writing for debuggers that very often catches bugs. The fact that this test will then break if "step" breaks doesn't bother me because a) this might be the only example where step breaks in this particular way, so that was actually a plus, and if something basic like step breaks we're going to fix it right away anyway 'cause it is step not working... I am also not against writing more focused tests when that is appropriate. But I am also pretty sure formal considerations are unlikely to outweigh this pretty consistent experience of writing tests for debuggers. Jim > On Jan 21, 2016, at 11:54 AM, Zachary Turner via lldb-commits > wrote: > > zturner added a comment. > > Right, but I don't agree in this case that "different" has to mean "we > discourage the use of reduced test cases". I have a hard time imagining a > scenario where not having reduced test cases is an advantage. It's also > easy to explain to people. "Write reduced test cases". It's easy to > understand. Moreso than "Reduced test cases are good, but not always > because fuzziness, but we can't really put into words exactly what amount > of fuzziness we want, or what it should look like, so I guess anything goes > > - don't ask don't tell". > > If we want fuzziness, we should do fuzz testing. Feature tests and > regression tests should be reduced. The whole reason the tests in > lldb/tests were written is because people were testing a specific feature > or bugfix. I don't see a reason to add fuzziness to this kind of test. > All it does is pollute failure logs. Fuzziness is better tested by fuzz > tests. > > > http://reviews.llvm.org/D16334 > > > > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16423: test suite: fix exception if --platform-name is specified that doesn't start with "remote-"
tfiala added a subscriber: emaste. tfiala added a comment. Hi Ed - not sure if freebsd still needs the set of expected timeout tests. If you were to run with --rerun-all-issues, then all tests are eligible for a rerun on the first failure/timeout/error/whatever. (expected failure- and the expected timeout-decorated tests are always eligible for rerun regardless of the --rerun-all-issues flag). If you don't end up needing these expected timeout tests, we can get rid of this whole method. http://reviews.llvm.org/D16423 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16415: Call CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. I just added PECOFF so I could make sure I had 3 clients for the ObjectFile class when I was developing it and I already have the PECOFF support in the previous tool I had written, so this is quite fine to do. I could even fine a PECOFF file that had a symbol table when I made ObjectFilePECOFF so I wasn't able to actually use any of the symbols. We don't use PECOFF at Apple, so this looks good. http://reviews.llvm.org/D16415 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258429 - Add CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab to ensure that (nearly) all the symbols have sizes.
Author: amccarth Date: Thu Jan 21 14:58:12 2016 New Revision: 258429 URL: http://llvm.org/viewvc/llvm-project?rev=258429&view=rev Log: Add CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab to ensure that (nearly) all the symbols have sizes. This fixes the `thread step-over` regression exposed by http://reviews.llvm.org/D16186 , which depends on the symbols having actual sizes. Nine tests on Windows had started failing as a result. They all work again with this fix. Differential Revision: http://reviews.llvm.org/D16415 Modified: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp Modified: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp?rev=258429&r1=258428&r2=258429&view=diff == --- lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp (original) +++ lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp Thu Jan 21 14:58:12 2016 @@ -649,6 +649,7 @@ ObjectFilePECOFF::GetSymtab() symbols[i].SetDebug(true); } } +m_symtab_ap->CalculateSymbolSizes(); } } return m_symtab_ap.get(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16415: Call CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab
This revision was automatically updated to reflect the committed changes. Closed by commit rL258429: Add CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab to ensure that… (authored by amccarth). Changed prior to commit: http://reviews.llvm.org/D16415?vs=45560&id=45586#toc Repository: rL LLVM http://reviews.llvm.org/D16415 Files: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp Index: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp === --- lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp +++ lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp @@ -649,6 +649,7 @@ symbols[i].SetDebug(true); } } +m_symtab_ap->CalculateSymbolSizes(); } } return m_symtab_ap.get(); Index: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp === --- lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp +++ lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp @@ -649,6 +649,7 @@ symbols[i].SetDebug(true); } } +m_symtab_ap->CalculateSymbolSizes(); } } return m_symtab_ap.get(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16247: Don't assume that thread 0 is always the main thread
This revision was automatically updated to reflect the committed changes. Closed by commit rL258432: Remove assumptions that thread 0 is always the main thread. (authored by zturner). Changed prior to commit: http://reviews.llvm.org/D16247?vs=45302&id=45587#toc Repository: rL LLVM http://reviews.llvm.org/D16247 Files: lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/conditional_break/TestConditionalBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/multi_break/TestMultipleBreakpoints.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py lldb/trunk/packages/Python/lldbsuite/test/lang/c/array_types/TestArrayTypes.py lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypes.py lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypesDisassembly.py lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/diamond/TestDiamond.py lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/inlines/TestInlinedFrame.py lldb/trunk/packages/Python/lldbsuite/test/python_api/hello_world/TestHelloWorld.py lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypesDisassembly.py === --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypesDisassembly.py +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypesDisassembly.py @@ -46,7 +46,8 @@ # disassemble it. target = self.dbg.GetSelectedTarget() process = target.GetProcess() -thread = process.GetThreadAtIndex(0) +thread = lldbutil.get_stopped_thread(process, lldb.eStopReasonBreakpoint) +self.assertIsNotNone(thread) depth = thread.GetNumFrames() for i in range(depth - 1): frame = thread.GetFrameAtIndex(i) Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypes.py === --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypes.py +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypes.py @@ -92,11 +92,8 @@ lldbutil.state_type_to_str(process.GetState())) # The stop reason of the thread should be breakpoint. -thread = process.GetThreadAtIndex(0) -if thread.GetStopReason() != lldb.eStopReasonBreakpoint: -from lldbsuite.test.lldbutil import stop_reason_to_str -self.fail(STOPPED_DUE_TO_BREAKPOINT_WITH_STOP_REASON_AS % - stop_reason_to_str(thread.GetStopReason())) +thread = lldbutil.get_stopped_thread(process, lldb.eStopReasonBreakpoint) +self.assertIsNotNone(thread) # The filename of frame #0 should be 'main.cpp' and the line number # should be 93. @@ -203,11 +200,8 @@ lldbutil.state_type_to_str(process.GetState())) # The stop reason of the thread should be breakpoint. -thread = process.GetThreadAtIndex(0) -if thread.GetStopReason() != lldb.eStopReasonBreakpoint: -from lldbsuite.test.lldbutil import stop_reason_to_str -self.fail(STOPPED_DUE_TO_BREAKPOINT_WITH_STOP_REASON_AS % - stop_reason_to_str(thread.GetStopReason())) +thread = lldbutil.get_stopped_thread(process, lldb.eStopReasonBreakpoint) +self.assertIsNotNone(thread) frame = thread.frames[0] self.assertTrue (frame.IsValid(), "Got a valid frame.") Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py === --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py @@ -69,11 +69,8 @@ self.assertTrue(process, PROCESS_IS_VALID) # The stop reason of the thread should be breakpoint. -thread = process.GetThreadAtIndex(0) -if thread.GetStopReason() != lldb.eStopReason
[Lldb-commits] [lldb] r258432 - Remove assumptions that thread 0 is always the main thread.
Author: zturner
Date: Thu Jan 21 15:07:30 2016
New Revision: 258432
URL: http://llvm.org/viewvc/llvm-project?rev=258432&view=rev
Log:
Remove assumptions that thread 0 is always the main thread.
Starting with Windows 10, the Windows loader is itself multi-threaded,
meaning that the loader spins up a few threads to do process
initialization before it executes main. Windows delivers these
notifications asynchronously and they can come out of order, so
we can't be sure that the first thread we get a notification about
is actually the zero'th thread.
This patch fixes this by requesting the thread stopped at the
breakpoint that was specified, rather than getting thread 0 and
verifying that it is stopped at a breakpoint.
Differential Revision: http://reviews.llvm.org/D16247
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/conditional_break/TestConditionalBreak.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/multi_break/TestMultipleBreakpoints.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/array_types/TestArrayTypes.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypes.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypesDisassembly.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/diamond/TestDiamond.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py
lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/inlines/TestInlinedFrame.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/hello_world/TestHelloWorld.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py?rev=258432&r1=258431&r2=258432&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
Thu Jan 21 15:07:30 2016
@@ -130,12 +130,8 @@ class BasicExprCommandsTestCase(TestBase
"instead the actual state is: '%s'" %
lldbutil.state_type_to_str(process.GetState()))
-# The stop reason of the thread should be breakpoint.
-thread = process.GetThreadAtIndex(0)
-if thread.GetStopReason() != lldb.eStopReasonBreakpoint:
-from lldbsuite.test.lldbutil import stop_reason_to_str
-self.fail(STOPPED_DUE_TO_BREAKPOINT_WITH_STOP_REASON_AS %
- stop_reason_to_str(thread.GetStopReason()))
+thread = lldbutil.get_one_thread_stopped_at_breakpoint(process,
breakpoint)
+self.assertIsNotNone(thread, "Expected one thread to be stopped at the
breakpoint")
# The filename of frame #0 should be 'main.cpp' and function is main.
self.expect(lldbutil.get_filenames(thread)[0],
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py?rev=258432&r1=258431&r2=258432&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
Thu Jan 21 15:07:30 2016
@@ -27,7 +27,7 @@ class ConsecutiveBreakpoitsTestCase(Test
target = self.dbg.CreateTarget(exe)
self.assertTrue(target, VALID_TARGET)
-breakpoint = target.BreakpointCreateBySourceRegex("Set breakpoint
here", lldb.SBFileSpec("main.cpp"))
+breakpoint1 = target.BreakpointCreateBySourceRegex("Set breakpoint
here", lldb.SBFileSpec("main.cpp"))
self.assertTrue(breakpoint and
[Lldb-commits] [lldb] r258433 - NFC. Corrects name of test class and a comment.
Author: amccarth
Date: Thu Jan 21 15:10:00 2016
New Revision: 258433
URL: http://llvm.org/viewvc/llvm-project?rev=258433&view=rev
Log:
NFC. Corrects name of test class and a comment.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/signed_types/TestSignedTypes.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/signed_types/TestSignedTypes.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/signed_types/TestSignedTypes.py?rev=258433&r1=258432&r2=258433&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/signed_types/TestSignedTypes.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/signed_types/TestSignedTypes.py
Thu Jan 21 15:10:00 2016
@@ -12,7 +12,7 @@ import lldb
from lldbsuite.test.lldbtest import *
import lldbsuite.test.lldbutil as lldbutil
-class UnsignedTypesTestCase(TestBase):
+class SignedTypesTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
@@ -48,7 +48,7 @@ class UnsignedTypesTestCase(TestBase):
self.expect("breakpoint list -f", BREAKPOINT_HIT_ONCE,
substrs = [' resolved, hit count = 1'])
-# Execute the assignment statement.
+# Execute the puts().
self.runCmd("thread step-over")
# Test that signed types display correctly.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
So, I don't actually disagree that the idea of doing a "step and see if it still works" is ok. Because I think that -- by itself -- is useful as an additional check. I'm not against doing extra work in a test when it adds something concretely useful to the test. So I still think we should reduce all test cases as much as possible, but as long as we can justify each operation as adding additional robustness to that particular test, I'm fine with it. That said, I don't think we should discourage finding better ways to test something either. If someone comes up with a different approach to writing a test for a particular feature, and that approach relies on less debugger functionality, but still tests the feature in question in , I think that should be encouraged. More granular tests give more clues as to the nature of the underlying problem, less false positives on failures, and make the test suite run faster. On Thu, Jan 21, 2016 at 12:04 PM Jim Ingham wrote: > I'm not sure this is a terribly productive discussion. > > Since I know that the debugger is stateful, when I write a test where I > get to point A and do thing X, I will often add - while I'm there - "step > again and see if it still works" or something morally equivalent to that. > I have found that to be a method of test writing for debuggers that very > often catches bugs. The fact that this test will then break if "step" > breaks doesn't bother me because a) this might be the only example where > step breaks in this particular way, so that was actually a plus, and if > something basic like step breaks we're going to fix it right away anyway > 'cause it is step not working... > > I am also not against writing more focused tests when that is > appropriate. But I am also pretty sure formal considerations are unlikely > to outweigh this pretty consistent experience of writing tests for > debuggers. > > Jim > > > On Jan 21, 2016, at 11:54 AM, Zachary Turner via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > > > > zturner added a comment. > > > > Right, but I don't agree in this case that "different" has to mean "we > > discourage the use of reduced test cases". I have a hard time imagining > a > > scenario where not having reduced test cases is an advantage. It's also > > easy to explain to people. "Write reduced test cases". It's easy to > > understand. Moreso than "Reduced test cases are good, but not always > > because fuzziness, but we can't really put into words exactly what amount > > of fuzziness we want, or what it should look like, so I guess anything > goes > > > > - don't ask don't tell". > > > > If we want fuzziness, we should do fuzz testing. Feature tests and > > regression tests should be reduced. The whole reason the tests in > > lldb/tests were written is because people were testing a specific feature > > or bugfix. I don't see a reason to add fuzziness to this kind of test. > > All it does is pollute failure logs. Fuzziness is better tested by fuzz > > tests. > > > > > > http://reviews.llvm.org/D16334 > > > > > > > > ___ > > lldb-commits mailing list > > lldb-commits@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15527: Add ability to override JIT expr compiler options.
ldrumm updated this revision to Diff 45588.
ldrumm added a comment.
Address @spyffe's previous suggestions regarding modifying target options in
place. This allows for a simpler and more maintainable solution than previously
implemented, and requires no extra datatype definitions.
- removed unneccessary SetOverrideTargetOpts method.
- removed unused `OverrideExprOptions` type.
- GetOverrideExprOpts now takes a single clang::TargetOptions reference
argument which is modified in-place, and returns a bool value indicating
whether the options were modified by the runtime.
http://reviews.llvm.org/D15527
Files:
include/lldb/Target/LanguageRuntime.h
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -173,7 +173,7 @@
// 1. Create a new compiler instance.
m_compiler.reset(new CompilerInstance());
lldb::LanguageType frame_lang = expr.Language(); // defaults to lldb::eLanguageTypeUnknown
-lldb_private::LanguageRuntime::OverrideExprOptions *target_opts_override = nullptr;
+bool overridden_target_opts = false;
lldb_private::LanguageRuntime *lang_rt = nullptr;
lldb::TargetSP target_sp;
if (exe_scope)
@@ -195,83 +195,65 @@
log->Printf("Frame has language of type %s", Language::GetNameForLanguageType(frame_lang));
}
-// 2. Configure the target, overriding with any custom options we can get.
-if (lang_rt)
+// 2. Configure the compiler with a set of default options that are appropriate
+// for most situations.
+if (target_sp && target_sp->GetArchitecture().IsValid())
{
-// The expression is being evaluated in a known LanguageRuntime and StackFrame.
-// We check if there are any overridden options for the evaluation, and configure
-// the compiler appropriately.
-target_opts_override = lang_rt->GetOverrideExprOptions();
+std::string triple = target_sp->GetArchitecture().GetTriple().str();
+m_compiler->getTargetOpts().Triple = triple;
+if (log)
+log->Printf("Using %s as the target triple", m_compiler->getTargetOpts().Triple.c_str());
}
-
-if (target_opts_override)
+else
{
+// If we get here we don't have a valid target and just have to guess.
+// Sometimes this will be ok to just use the host target triple (when we evaluate say "2+3", but other
+// expressions like breakpoint conditions and other things that _are_ target specific really shouldn't just be
+// using the host triple. In such a case the language runtime should expose an overridden options set (3),
+// below.
+m_compiler->getTargetOpts().Triple = llvm::sys::getDefaultTargetTriple();
if (log)
-log->Debug("Using overridden target options for the expression evaluation");
-
-// If we get here this means the given language runtime has a custom set of code
-// generation requirements, and they are configured from the language runtime.
-m_compiler->getTargetOpts().Features = target_opts_override->Features;
-m_compiler->getTargetOpts().CPU = target_opts_override->CPU;
-m_compiler->getTargetOpts().Triple = target_opts_override->Triple;
-m_compiler->getTargetOpts().FeaturesAsWritten = target_opts_override->FeaturesAsWritten;
-m_compiler->getTargetOpts().Reciprocals = target_opts_override->Reciprocals;
+log->Printf("Using default target triple of %s", m_compiler->getTargetOpts().Triple.c_str());
}
-else
+// Now add some special fixes for known architectures:
+// Any arm32 iOS environment, but not on arm64
+if (m_compiler->getTargetOpts().Triple.find("arm64") == std::string::npos &&
+m_compiler->getTargetOpts().Triple.find("arm") != std::string::npos &&
+m_compiler->getTargetOpts().Triple.find("ios") != std::string::npos)
{
-// In this case, a specialized language runtime is not available and
-// we have to fallback to making some basic assumptions on the target architecture.
-// For 99% of use cases, this will be fine and is assumed to be the default.
-if (target_sp && target_sp->GetArchitecture().IsValid())
-{
-std::string triple = target_sp->GetArchitecture().GetTriple().str();
-m_compiler->getTargetOpts().Triple = triple;
-if (log)
-log->Printf("Using %s as the target triple", m_compiler->getTargetOpts().Triple.c_str());
-}
-else
-{
-// If we get here we don't have a valid target and just have to guess.
-// Sometimes this will be ok to just use the host target triple (when we
-// ev
[Lldb-commits] [lldb] r258443 - Always try to read DW_TAG_typedef types from DWO files first if we can.
Author: gclayton
Date: Thu Jan 21 16:26:13 2016
New Revision: 258443
URL: http://llvm.org/viewvc/llvm-project?rev=258443&view=rev
Log:
Always try to read DW_TAG_typedef types from DWO files first if we can.
A lot of C code uses code like:
typedef struct
{
int a;
} FooType;
This creates debug info with an anonymous struct (a DW_TAG_structure_type with
no DW_AT_name) and then a DW_TAG_typedef that points to the anonymous structure
type. When a typedef is from a module and clang uses -gmodules and -fmodules,
then we can end up trying to resolve an anonymous structure type in a DWO
symbol file. This doesn't work very well when the structuture has no name, so
we now check if a typedef comes from a module, and we directly resolve the
typedef type in the module and copy it over. The version we copy from the
module of course is correctly able to find the structure in the DWO symbol
file, so this fixes the issues we run into.
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=258443&r1=258442&r2=258443&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Thu Jan
21 16:26:13 2016
@@ -252,11 +252,34 @@ DWARFASTParserClang::ParseTypeFromDWARF
switch (tag)
{
+case DW_TAG_typedef:
+// Try to parse a typedef from the DWO file first as
modules
+// can contain typedef'ed structures that have no names
like:
+//
+// typedef struct { int a; } Foo;
+//
+// In this case we will have a structure with no name and a
+// typedef named "Foo" that points to this unnamed
structure.
+// The name in the typedef is the only identifier for the
struct,
+// so always try to get typedefs from DWO files if
possible.
+//
+// The type_sp returned will be empty if the typedef
doesn't exist
+// in a DWO file, so it is cheap to call this function
just to check.
+//
+// If we don't do this we end up creating a TypeSP that
says this
+// is a typedef to type 0x123 (the DW_AT_type value would
be 0x123
+// in the DW_TAG_typedef), and this is the unnamed
structure type.
+// We will have a hard time tracking down an unnammed
structure
+// type in the module DWO file, so we make sure we don't
get into
+// this situation by always resolving typedefs from the
DWO file.
+type_sp = ParseTypeFromDWO(die, log);
+if (type_sp)
+return type_sp;
+
case DW_TAG_base_type:
case DW_TAG_pointer_type:
case DW_TAG_reference_type:
case DW_TAG_rvalue_reference_type:
-case DW_TAG_typedef:
case DW_TAG_const_type:
case DW_TAG_restrict_type:
case DW_TAG_volatile_type:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D16431: Fix TestImport.py to work with Python 3.5.
amccarth created this revision.
amccarth added a reviewer: zturner.
amccarth added a subscriber: lldb-commits.
In Python 3.5, import looks only in the official packages directory unless you
tell it otherwise. I tested with Python 2.7 as well.
http://reviews.llvm.org/D16431
Files:
packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
Index:
packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
===
---
packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
+++
packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
@@ -1,5 +1,7 @@
-import TPunitA
-import TPunitB
+from __future__ import absolute_import
+
+from . import TPunitA
+from . import TPunitB
def __lldb_init_module(debugger,*args):
debugger.HandleCommand("command script add -f
thepackage.TPunitA.command TPcommandA")
Index: packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
===
--- packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
+++ packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
@@ -1,5 +1,7 @@
-import TPunitA
-import TPunitB
+from __future__ import absolute_import
+
+from . import TPunitA
+from . import TPunitB
def __lldb_init_module(debugger,*args):
debugger.HandleCommand("command script add -f thepackage.TPunitA.command TPcommandA")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16431: Fix TestImport.py to work with Python 3.5.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL258448: Fix TestImport.py to work with Python 3.5. (authored
by amccarth).
Changed prior to commit:
http://reviews.llvm.org/D16431?vs=45600&id=45603#toc
Repository:
rL LLVM
http://reviews.llvm.org/D16431
Files:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
@@ -1,5 +1,7 @@
-import TPunitA
-import TPunitB
+from __future__ import absolute_import
+
+from . import TPunitA
+from . import TPunitB
def __lldb_init_module(debugger,*args):
debugger.HandleCommand("command script add -f
thepackage.TPunitA.command TPcommandA")
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
@@ -1,5 +1,7 @@
-import TPunitA
-import TPunitB
+from __future__ import absolute_import
+
+from . import TPunitA
+from . import TPunitB
def __lldb_init_module(debugger,*args):
debugger.HandleCommand("command script add -f thepackage.TPunitA.command TPcommandA")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258448 - Fix TestImport.py to work with Python 3.5.
Author: amccarth
Date: Thu Jan 21 17:07:48 2016
New Revision: 258448
URL: http://llvm.org/viewvc/llvm-project?rev=258448&view=rev
Log:
Fix TestImport.py to work with Python 3.5.
Differential Revision: http://reviews.llvm.org/D16431
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py?rev=258448&r1=258447&r2=258448&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/thepackage/__init__.py
Thu Jan 21 17:07:48 2016
@@ -1,5 +1,7 @@
-import TPunitA
-import TPunitB
+from __future__ import absolute_import
+
+from . import TPunitA
+from . import TPunitB
def __lldb_init_module(debugger,*args):
debugger.HandleCommand("command script add -f
thepackage.TPunitA.command TPcommandA")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258481 - [opaque pointer types] [NFC] Fix fallout from DataLayout::getIndexedOffset changes (rL258478).
Author: eddyb Date: Thu Jan 21 21:43:23 2016 New Revision: 258481 URL: http://llvm.org/viewvc/llvm-project?rev=258481&view=rev Log: [opaque pointer types] [NFC] Fix fallout from DataLayout::getIndexedOffset changes (rL258478). Modified: lldb/trunk/source/Expression/IRInterpreter.cpp Modified: lldb/trunk/source/Expression/IRInterpreter.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRInterpreter.cpp?rev=258481&r1=258480&r2=258481&view=diff == --- lldb/trunk/source/Expression/IRInterpreter.cpp (original) +++ lldb/trunk/source/Expression/IRInterpreter.cpp Thu Jan 21 21:43:23 2016 @@ -33,6 +33,7 @@ #include "llvm/IR/Intrinsics.h" #include "llvm/IR/LLVMContext.h" #include "llvm/IR/Module.h" +#include "llvm/IR/Operator.h" #include "llvm/Support/raw_ostream.h" #include @@ -297,7 +298,8 @@ public: SmallVector indices (op_cursor, op_end); -uint64_t offset = m_target_data.getIndexedOffset(base->getType(), indices); +Type *src_elem_ty = cast(constant_expr)->getSourceElementType(); +uint64_t offset = m_target_data.getIndexedOffsetInType(src_elem_ty, indices); const bool is_signed = true; value += APInt(value.getBitWidth(), offset, is_signed); @@ -999,7 +1001,7 @@ IRInterpreter::Interpret (llvm::Module & } const Value *pointer_operand = gep_inst->getPointerOperand(); -Type *pointer_type = pointer_operand->getType(); +Type *src_elem_ty = gep_inst->getSourceElementType(); lldb_private::Scalar P; @@ -1048,7 +1050,7 @@ IRInterpreter::Interpret (llvm::Module & const_indices.push_back(constant_index); } -uint64_t offset = data_layout.getIndexedOffset(pointer_type, const_indices); +uint64_t offset = data_layout.getIndexedOffsetInType(src_elem_ty, const_indices); lldb_private::Scalar Poffset = P + offset; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258485 - Use "_$" prefix instead of "$" for dynamic checker function inserted by LLDB during expression evaluation
Author: bhushan.attarde
Date: Thu Jan 21 23:02:02 2016
New Revision: 258485
URL: http://llvm.org/viewvc/llvm-project?rev=258485&view=rev
Log:
Use "_$" prefix instead of "$" for dynamic checker function inserted by LLDB
during expression evaluation
SUMMARY:
The symbol "$" has a special meaning for MIPS i.e it is marker for
temporary symbols for MIPS.
So this patch uses additional _ prefix for "$__lldb_valid_pointer_check" so
that it wont be marked as temporary symbol in case of MIPS.
Reviewers: clayborg, spyffe
Subscribers: dean, emaste, mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential http://reviews.llvm.org/D14111
Modified:
lldb/trunk/source/Expression/IRDynamicChecks.cpp
Modified: lldb/trunk/source/Expression/IRDynamicChecks.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRDynamicChecks.cpp?rev=258485&r1=258484&r2=258485&view=diff
==
--- lldb/trunk/source/Expression/IRDynamicChecks.cpp (original)
+++ lldb/trunk/source/Expression/IRDynamicChecks.cpp Thu Jan 21 23:02:02 2016
@@ -35,12 +35,12 @@ using namespace lldb_private;
static char ID;
-#define VALID_POINTER_CHECK_NAME "$__lldb_valid_pointer_check"
+#define VALID_POINTER_CHECK_NAME "_$__lldb_valid_pointer_check"
#define VALID_OBJC_OBJECT_CHECK_NAME "$__lldb_objc_object_check"
static const char g_valid_pointer_check_text[] =
"extern \"C\" void\n"
-"$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
+"_$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
"{\n"
"unsigned char $__lldb_local_val = *$__lldb_arg_ptr;\n"
"}";
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D14111: Use "_$" prefix instead of "$" for dynamic checker function inserted by LLDB during expression evaluation
bhushan closed this revision. bhushan added a comment. Closed by commit http://reviews.llvm.org/rL258485 Repository: rL LLVM http://reviews.llvm.org/D14111 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
