Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux
Technically, it's the combination of -Werror and -pedantic which is causing the problem. Any single one of them would be fine :) I am not sure what could be the problem, LLDB's build files do not explicitly add any of these flags, so they must be coming from somewhere else. Without more information, it's hard to say from where. If you send me your cmake command line, I can try to reproduce the problem. Otherwise, you're pretty much on your own. All I can recommend is to try the --trace cmake argument, which may give you an idea where are those flags coming from. pl On 12 May 2017 at 19:21, Andy Gibbs wrote: > Sorry not to have come back sooner. > > > The problem is not the -Werror (I think) but the -pedantic that gets added > during lldb configuration. Having looked through the cmake files, I cannot > see how this is added though. Interestingly enough the backtrace detection > is run earlier in configuration, possibly in the llvm part itself, where it > passes without problem. The only difference in the log file is that earlier > on there is no -pedantic option given. > > > Also, although this is an aside, if clang is the compiler, it also passes > (with the -pedantic). Problem is, then I need to build clang to build clang > :o) > > > Cheers, > > Andy > > > > > From: Zachary Turner > Sent: 02 May 2017 13:50 > To: Pavel Labath; Andy Gibbs > Cc: lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux > > This is in cmake detection code though, the options you set for your build > have no bearing there right? > > This looks like a bug in cmake to me, perhaps a newer cmake version can fix > it? > On Tue, May 2, 2017 at 3:24 AM Pavel Labath via lldb-dev > wrote: >> >> What's the cmake command you are using? >> >> It sounds like you somehow ended up enabling -Werror, which is >> confusing the backtrace-detection code (and probably most of the other >> cmake compile checks). >> >> One of the workarounds would be to disable -Werror. >> >> pl >> >> On 28 April 2017 at 22:36, Andy Gibbs via lldb-dev >> wrote: >> > Hi, >> > >> > >> > I am having a problem building the 4.0 release branch of LLDB on Debian >> > Stretch. Cmake returns the following fault: >> > >> > >> > -- LLDB version: 4.0.0 >> > -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version >> > "2.9.4") >> > -- Performing Test HAVE_PROCESS_VM_READV >> > -- Performing Test HAVE_PROCESS_VM_READV - Success >> > -- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so >> > -- Looking for __GLIBCXX__ >> > -- Looking for __GLIBCXX__ - found >> > -- Performing Test LLDB_USING_LIBSTDCXX_4_9 >> > -- Performing Test LLDB_USING_LIBSTDCXX_4_9 - Success >> > -- Looking for backtrace >> > -- Looking for backtrace - not found >> > -- Could NOT find Backtrace (missing: Backtrace_LIBRARY) >> > -- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") >> > -- Found SWIG: /usr/bin/swig3.0 (found version "3.0.10") >> > -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED >> > -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED - Success >> > -- Symbols (liblldb): exporting all symbols from the lldb namespace >> > CMake Error: The following variables are used in this project, but >> > they >> > are set to NOTFOUND. >> > Please set them or make sure they are set and tested correctly in the >> > CMake files: >> > Backtrace_LIBRARY (ADVANCED) >> > linked by target "liblldb" in directory >> > clang-4.0/tools/lldb/source/API >> > linked by target "LLDBBreakpointTests" in directory >> > clang-4.0/tools/lldb/unittests/Breakpoint >> > linked by target "LLDBCoreTests" in directory >> > clang-4.0/tools/lldb/unittests/Core >> > linked by target "EditlineTests" in directory >> > clang-4.0/tools/lldb/unittests/Editline >> > linked by target "ExpressionTests" in directory >> > clang-4.0/tools/lldb/unittests/Expression >> > linked by target "HostTests" in directory >> > clang-4.0/tools/lldb/unittests/Host >> > linked by target "InterpreterTests" in directory >> > clang-4.0/tools/lldb/unittests/Interpreter >> > linked by target "LanguageCPlusPlusTests" in directory >> > clang-4.0/tools/lldb/unittests/Language/CPlusPlus >> > linked by target "LLDBPlatformTests" in directory >> > clang-4.0/tools/lldb/unittests/Platform >> > linked by target "ProcessGdbRemoteTests" in directory >> > clang-4.0/tools/lldb/unittests/Process/gdb-remote >> > linked by target "LLDBMinidumpTests" in directory >> > clang-4.0/tools/lldb/unittests/Process/minidump >> > linked by target "ScriptInterpreterPythonTests" in directory >> > clang-4.0/tools/lldb/unittests/ScriptInterpreter/Python >> > linked by target "SymbolTests" in directory >> > clang-4.0/tools/lldb/unittests/Symbol >> > linked by target "SymbolFileDWARFTests" in directory >> > clang-4.0/tools/lldb/unittests/SymbolFile/DWARF >> > linked by t
Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux
Again, this has nothing to do with our build files, it is in cmakes internal builtin modules when it is trying to compile a program to see if a symbol exists. This looks like a cmake bug, try upgrading cmake On Mon, May 15, 2017 at 1:25 AM Pavel Labath wrote: > Technically, it's the combination of -Werror and -pedantic which is > causing the problem. Any single one of them would be fine :) > > I am not sure what could be the problem, LLDB's build files do not > explicitly add any of these flags, so they must be coming from > somewhere else. Without more information, it's hard to say from where. > If you send me your cmake command line, I can try to reproduce the > problem. Otherwise, you're pretty much on your own. All I can > recommend is to try the --trace cmake argument, which may give you an > idea where are those flags coming from. > > pl > > On 12 May 2017 at 19:21, Andy Gibbs wrote: > > Sorry not to have come back sooner. > > > > > > The problem is not the -Werror (I think) but the -pedantic that gets > added > > during lldb configuration. Having looked through the cmake files, I > cannot > > see how this is added though. Interestingly enough the backtrace > detection > > is run earlier in configuration, possibly in the llvm part itself, where > it > > passes without problem. The only difference in the log file is that > earlier > > on there is no -pedantic option given. > > > > > > Also, although this is an aside, if clang is the compiler, it also passes > > (with the -pedantic). Problem is, then I need to build clang to build > clang > > :o) > > > > > > Cheers, > > > > Andy > > > > > > > > > > From: Zachary Turner > > Sent: 02 May 2017 13:50 > > To: Pavel Labath; Andy Gibbs > > Cc: lldb-dev@lists.llvm.org > > Subject: Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux > > > > This is in cmake detection code though, the options you set for your > build > > have no bearing there right? > > > > This looks like a bug in cmake to me, perhaps a newer cmake version can > fix > > it? > > On Tue, May 2, 2017 at 3:24 AM Pavel Labath via lldb-dev > > wrote: > >> > >> What's the cmake command you are using? > >> > >> It sounds like you somehow ended up enabling -Werror, which is > >> confusing the backtrace-detection code (and probably most of the other > >> cmake compile checks). > >> > >> One of the workarounds would be to disable -Werror. > >> > >> pl > >> > >> On 28 April 2017 at 22:36, Andy Gibbs via lldb-dev > >> wrote: > >> > Hi, > >> > > >> > > >> > I am having a problem building the 4.0 release branch of LLDB on > Debian > >> > Stretch. Cmake returns the following fault: > >> > > >> > > >> > -- LLDB version: 4.0.0 > >> > -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found > version > >> > "2.9.4") > >> > -- Performing Test HAVE_PROCESS_VM_READV > >> > -- Performing Test HAVE_PROCESS_VM_READV - Success > >> > -- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so > >> > -- Looking for __GLIBCXX__ > >> > -- Looking for __GLIBCXX__ - found > >> > -- Performing Test LLDB_USING_LIBSTDCXX_4_9 > >> > -- Performing Test LLDB_USING_LIBSTDCXX_4_9 - Success > >> > -- Looking for backtrace > >> > -- Looking for backtrace - not found > >> > -- Could NOT find Backtrace (missing: Backtrace_LIBRARY) > >> > -- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") > >> > -- Found SWIG: /usr/bin/swig3.0 (found version "3.0.10") > >> > -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED > >> > -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED - Success > >> > -- Symbols (liblldb): exporting all symbols from the lldb namespace > >> > CMake Error: The following variables are used in this project, but > >> > they > >> > are set to NOTFOUND. > >> > Please set them or make sure they are set and tested correctly in > the > >> > CMake files: > >> > Backtrace_LIBRARY (ADVANCED) > >> > linked by target "liblldb" in directory > >> > clang-4.0/tools/lldb/source/API > >> > linked by target "LLDBBreakpointTests" in directory > >> > clang-4.0/tools/lldb/unittests/Breakpoint > >> > linked by target "LLDBCoreTests" in directory > >> > clang-4.0/tools/lldb/unittests/Core > >> > linked by target "EditlineTests" in directory > >> > clang-4.0/tools/lldb/unittests/Editline > >> > linked by target "ExpressionTests" in directory > >> > clang-4.0/tools/lldb/unittests/Expression > >> > linked by target "HostTests" in directory > >> > clang-4.0/tools/lldb/unittests/Host > >> > linked by target "InterpreterTests" in directory > >> > clang-4.0/tools/lldb/unittests/Interpreter > >> > linked by target "LanguageCPlusPlusTests" in directory > >> > clang-4.0/tools/lldb/unittests/Language/CPlusPlus > >> > linked by target "LLDBPlatformTests" in directory > >> > clang-4.0/tools/lldb/unittests/Platform > >> > linked by target "ProcessGdbRemoteTests" in directory > >> > clang-4.0/tools/lldb/unit
Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux
If you set enough cmake variables, you can certainly force cmake to do the build checks with -Werror. I am asking for the build command to rule that out (among other things) On 15 May 2017 at 11:57, Zachary Turner wrote: > Again, this has nothing to do with our build files, it is in cmakes internal > builtin modules when it is trying to compile a program to see if a symbol > exists. This looks like a cmake bug, try upgrading cmake > On Mon, May 15, 2017 at 1:25 AM Pavel Labath wrote: >> >> Technically, it's the combination of -Werror and -pedantic which is >> causing the problem. Any single one of them would be fine :) >> >> I am not sure what could be the problem, LLDB's build files do not >> explicitly add any of these flags, so they must be coming from >> somewhere else. Without more information, it's hard to say from where. >> If you send me your cmake command line, I can try to reproduce the >> problem. Otherwise, you're pretty much on your own. All I can >> recommend is to try the --trace cmake argument, which may give you an >> idea where are those flags coming from. >> >> pl >> >> On 12 May 2017 at 19:21, Andy Gibbs wrote: >> > Sorry not to have come back sooner. >> > >> > >> > The problem is not the -Werror (I think) but the -pedantic that gets >> > added >> > during lldb configuration. Having looked through the cmake files, I >> > cannot >> > see how this is added though. Interestingly enough the backtrace >> > detection >> > is run earlier in configuration, possibly in the llvm part itself, where >> > it >> > passes without problem. The only difference in the log file is that >> > earlier >> > on there is no -pedantic option given. >> > >> > >> > Also, although this is an aside, if clang is the compiler, it also >> > passes >> > (with the -pedantic). Problem is, then I need to build clang to build >> > clang >> > :o) >> > >> > >> > Cheers, >> > >> > Andy >> > >> > >> > >> > >> > From: Zachary Turner >> > Sent: 02 May 2017 13:50 >> > To: Pavel Labath; Andy Gibbs >> > Cc: lldb-dev@lists.llvm.org >> > Subject: Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux >> > >> > This is in cmake detection code though, the options you set for your >> > build >> > have no bearing there right? >> > >> > This looks like a bug in cmake to me, perhaps a newer cmake version can >> > fix >> > it? >> > On Tue, May 2, 2017 at 3:24 AM Pavel Labath via lldb-dev >> > wrote: >> >> >> >> What's the cmake command you are using? >> >> >> >> It sounds like you somehow ended up enabling -Werror, which is >> >> confusing the backtrace-detection code (and probably most of the other >> >> cmake compile checks). >> >> >> >> One of the workarounds would be to disable -Werror. >> >> >> >> pl >> >> >> >> On 28 April 2017 at 22:36, Andy Gibbs via lldb-dev >> >> wrote: >> >> > Hi, >> >> > >> >> > >> >> > I am having a problem building the 4.0 release branch of LLDB on >> >> > Debian >> >> > Stretch. Cmake returns the following fault: >> >> > >> >> > >> >> > -- LLDB version: 4.0.0 >> >> > -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found >> >> > version >> >> > "2.9.4") >> >> > -- Performing Test HAVE_PROCESS_VM_READV >> >> > -- Performing Test HAVE_PROCESS_VM_READV - Success >> >> > -- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so >> >> > -- Looking for __GLIBCXX__ >> >> > -- Looking for __GLIBCXX__ - found >> >> > -- Performing Test LLDB_USING_LIBSTDCXX_4_9 >> >> > -- Performing Test LLDB_USING_LIBSTDCXX_4_9 - Success >> >> > -- Looking for backtrace >> >> > -- Looking for backtrace - not found >> >> > -- Could NOT find Backtrace (missing: Backtrace_LIBRARY) >> >> > -- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") >> >> > -- Found SWIG: /usr/bin/swig3.0 (found version "3.0.10") >> >> > -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED >> >> > -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED - Success >> >> > -- Symbols (liblldb): exporting all symbols from the lldb namespace >> >> > CMake Error: The following variables are used in this project, but >> >> > they >> >> > are set to NOTFOUND. >> >> > Please set them or make sure they are set and tested correctly in >> >> > the >> >> > CMake files: >> >> > Backtrace_LIBRARY (ADVANCED) >> >> > linked by target "liblldb" in directory >> >> > clang-4.0/tools/lldb/source/API >> >> > linked by target "LLDBBreakpointTests" in directory >> >> > clang-4.0/tools/lldb/unittests/Breakpoint >> >> > linked by target "LLDBCoreTests" in directory >> >> > clang-4.0/tools/lldb/unittests/Core >> >> > linked by target "EditlineTests" in directory >> >> > clang-4.0/tools/lldb/unittests/Editline >> >> > linked by target "ExpressionTests" in directory >> >> > clang-4.0/tools/lldb/unittests/Expression >> >> > linked by target "HostTests" in directory >> >> > clang-4.0/tools/lldb/unittests/Host >> >> > linked by target "InterpreterTests" in directo
[lldb-dev] lldb-server tests
Hello all, In case you haven't noticed it, I'd like to draw your attention to D32930, where we're proposing a new test framework for lldb-server tests. The discussion has so far been about low-level implementation details, so you don't have to read through it if you don't feel like to (but I do encourage it) However, I'd like to explain some of the high-level motivations which led to our proposed design and open a discussion on them here. I'll do this in an FAQ form: :) - why new framework?: Lldb-server tests were never really suited for the dotest.py model anyway (for example they end up creating an SBDebugger, only to be completely ignoring it and opening a socket connection to lldb-server directly). Perhaps for this reason, they are also harder to write than usual lldb tests, and a lot more messy internally (e.g., after Chris's ipv6 patch, which caused all lldb-server connections in the test to fail, I've learned that the test harness will attempt the lldb-server connection 400(!!!) times before conceding defeat). The test suite operation is also very illogical when it comes to doing remote tests: to test lldb-server on a remote target, you first have to build lldb-server for the target, THEN you have to build lldb for the HOST, and THEN you run dotest.py in the HOST build folder while passing funny dotest.py arguments. - why lldb-server ?: We'd like this to be a first step in porting the existing test off of the dotest.py test runner. Unlike the full test suite, the number of lldb-server tests is not that big, so porting them is an task achievable in a not too long timeframe, and it can serve as a proof of concept when considering further steps. Also, lldb-server already performs a relatively well-defined and simple task, which means it fits the llvm model of testing isolated components of functionality without the need for a massive refactor. - why c++ (aka, if the existing test suite is broken, why not just fix it) ?: There are two fundamental issues with the current test suite which cannot be easily "fixed". The first one is the remote execution (which is where a large part of the test harness complexity comes from). By writing the test in c++ we can run the test *and* lldb-server remotely (***), avoiding the network communication and flakyness that comes with it. The other issue is the fact that it needs to have a completely independent reimplementation of the gdb-remote protocol. Sure, some duplication is expected from tests, but it does not have to be that big. If we write the test in c++ we can reuse parts of the gdb-remote client code (thereby increasing test coverage of that as well), and only resort to manual packet parsing when we really want to (e.g., when testing the server response to a malformed packet or similar). - ok, but why not have the test described by a text file, and have a c++ FileCheck-like utility which interprets it?: Due to the unpredictable (e.g. we cannot control the addresses of objects in the inferior), and interactive nature of the tests, we believe they would be easier to write imperatively, instead of a more declarative FileCheck style. E.g. for one test you need to send qRegisterInfoN for N=1,... until you find the pc register then pluck a field with that number from a stop-reply packet, and compare that the result of another packet, while possible reversing endianness. To describe something like this in a text file, you will either need primitives to describe loops, conditionals, etc (which will then tend towards implementing a full scripting language), or have a very high-level primitive operation which does exactly this, which will tend towards having many specialized primitive operations. regards, pavel (***) To achieve this, we want to propose adding the ability to execute tests remotely to llvm-lit, which we hope will be useful to more people. I'll write more about this in a separate email with llvm-dev included. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-server tests
Thank you for this work. I will add a usual requirement - please make sure that "check-lldb-unit" works in standalone builds. On 15.05.2017 16:33, Pavel Labath wrote: > Hello all, > > In case you haven't noticed it, I'd like to draw your attention to > D32930, where we're proposing a new test framework for lldb-server > tests. The discussion has so far been about low-level implementation > details, so you don't have to read through it if you don't feel like > to (but I do encourage it) > > However, I'd like to explain some of the high-level motivations which > led to our proposed design and open a discussion on them here. I'll do > this in an FAQ form: :) > > - why new framework?: > > Lldb-server tests were never really suited for the dotest.py model > anyway (for example they end up creating an SBDebugger, only to be > completely ignoring it and opening a socket connection to lldb-server > directly). Perhaps for this reason, they are also harder to write than > usual lldb tests, and a lot more messy internally (e.g., after Chris's > ipv6 patch, which caused all lldb-server connections in the test to > fail, I've learned that the test harness will attempt the lldb-server > connection 400(!!!) times before conceding defeat). The test suite > operation is also very illogical when it comes to doing remote tests: > to test lldb-server on a remote target, you first have to build > lldb-server for the target, THEN you have to build lldb for the HOST, > and THEN you run dotest.py in the HOST build folder while passing > funny dotest.py arguments. > > > - why lldb-server ?: > We'd like this to be a first step in porting the existing test off of > the dotest.py test runner. Unlike the full test suite, the number of > lldb-server tests is not that big, so porting them is an task > achievable in a not too long timeframe, and it can serve as a proof of > concept when considering further steps. Also, lldb-server already > performs a relatively well-defined and simple task, which means it > fits the llvm model of testing isolated components of functionality > without the need for a massive refactor. > > - why c++ (aka, if the existing test suite is broken, why not just fix it) ?: > There are two fundamental issues with the current test suite which > cannot be easily "fixed". The first one is the remote execution (which > is where a large part of the test harness complexity comes from). By > writing the test in c++ we can run the test *and* lldb-server remotely > (***), avoiding the network communication and flakyness that comes > with it. The other issue is the fact that it needs to have a > completely independent reimplementation of the gdb-remote protocol. > Sure, some duplication is expected from tests, but it does not have to > be that big. If we write the test in c++ we can reuse parts of the > gdb-remote client code (thereby increasing test coverage of that as > well), and only resort to manual packet parsing when we really want to > (e.g., when testing the server response to a malformed packet or > similar). > > - ok, but why not have the test described by a text file, and have a > c++ FileCheck-like utility which interprets it?: > Due to the unpredictable (e.g. we cannot control the addresses of > objects in the inferior), and interactive nature of the tests, we > believe they would be easier to write imperatively, instead of a more > declarative FileCheck style. E.g. for one test you need to send > qRegisterInfoN for N=1,... until you find the pc register then pluck a > field with that number from a stop-reply packet, and compare that the > result of another packet, while possible reversing endianness. To > describe something like this in a text file, you will either need > primitives to describe loops, conditionals, etc (which will then tend > towards implementing a full scripting language), or have a very > high-level primitive operation which does exactly this, which will > tend towards having many specialized primitive operations. > > regards, > pavel > > (***) To achieve this, we want to propose adding the ability to > execute tests remotely to llvm-lit, which we hope will be useful to > more people. I'll write more about this in a separate email with > llvm-dev included. > signature.asc Description: OpenPGP digital signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-server tests
One thing about lit that most people either don't understand or forget about is that FileCheck has nothing to do with lit. You can have lit tests without FileCheck. It's more work because you would have to define an LLDBServerTestFormat and invent some DSL that isn't just a bunch of run lines and check statements. You could then write a c++ program like lldb-server-test, which gives you all the benefits of code reuse and packet parsing that you're talking about, and have your test consist of something like: check-lldb-server --prefix=TEST_ERROR_RESPONSE < %s check-lldb-server --prefix=TEST_SUCCESS_RESPONSE < %s TEST_ERROR_RESPONSE: SEND: TEST_ERROR_RESPONSE: RECV-ERROR: 62 TEST_SUCCESS_RESPONSE: SEND: TEST_SUCCESS_RESPONSE: RECV-SUCCESS: eax = 7 I think this would make tests both easier to write and easier to understand than what is being proposed here. That said, what is being proposed here can't exactly be called a lateral move, because I do agree it's better. So because of that, I'm willing to let it go in. But I'm 100% confident that a better solution can be devised in lit with some thought. Unfortunately, given that I don't work on lldb-server, all I can really do is offer some high level ideas, and it will be up to you guys to figure out the details. On Mon, May 15, 2017 at 7:34 AM Pavel Labath wrote: > Hello all, > > In case you haven't noticed it, I'd like to draw your attention to > D32930, where we're proposing a new test framework for lldb-server > tests. The discussion has so far been about low-level implementation > details, so you don't have to read through it if you don't feel like > to (but I do encourage it) > > However, I'd like to explain some of the high-level motivations which > led to our proposed design and open a discussion on them here. I'll do > this in an FAQ form: :) > > - why new framework?: > > Lldb-server tests were never really suited for the dotest.py model > anyway (for example they end up creating an SBDebugger, only to be > completely ignoring it and opening a socket connection to lldb-server > directly). Perhaps for this reason, they are also harder to write than > usual lldb tests, and a lot more messy internally (e.g., after Chris's > ipv6 patch, which caused all lldb-server connections in the test to > fail, I've learned that the test harness will attempt the lldb-server > connection 400(!!!) times before conceding defeat). The test suite > operation is also very illogical when it comes to doing remote tests: > to test lldb-server on a remote target, you first have to build > lldb-server for the target, THEN you have to build lldb for the HOST, > and THEN you run dotest.py in the HOST build folder while passing > funny dotest.py arguments. > > > - why lldb-server ?: > We'd like this to be a first step in porting the existing test off of > the dotest.py test runner. Unlike the full test suite, the number of > lldb-server tests is not that big, so porting them is an task > achievable in a not too long timeframe, and it can serve as a proof of > concept when considering further steps. Also, lldb-server already > performs a relatively well-defined and simple task, which means it > fits the llvm model of testing isolated components of functionality > without the need for a massive refactor. > > - why c++ (aka, if the existing test suite is broken, why not just fix it) > ?: > There are two fundamental issues with the current test suite which > cannot be easily "fixed". The first one is the remote execution (which > is where a large part of the test harness complexity comes from). By > writing the test in c++ we can run the test *and* lldb-server remotely > (***), avoiding the network communication and flakyness that comes > with it. The other issue is the fact that it needs to have a > completely independent reimplementation of the gdb-remote protocol. > Sure, some duplication is expected from tests, but it does not have to > be that big. If we write the test in c++ we can reuse parts of the > gdb-remote client code (thereby increasing test coverage of that as > well), and only resort to manual packet parsing when we really want to > (e.g., when testing the server response to a malformed packet or > similar). > > - ok, but why not have the test described by a text file, and have a > c++ FileCheck-like utility which interprets it?: > Due to the unpredictable (e.g. we cannot control the addresses of > objects in the inferior), and interactive nature of the tests, we > believe they would be easier to write imperatively, instead of a more > declarative FileCheck style. E.g. for one test you need to send > qRegisterInfoN for N=1,... until you find the pc register then pluck a > field with that number from a stop-reply packet, and compare that the > result of another packet, while possible reversing endianness. To > describe something like this in a text file, you will either need > primitives to describe loops, conditionals, etc (which will then tend > towards imp
[lldb-dev] [Bug 33042] New: Unable to read return value of arm64 functions returning large objects
https://bugs.llvm.org/show_bug.cgi?id=33042 Bug ID: 33042 Summary: Unable to read return value of arm64 functions returning large objects Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org Aarch64 Procedure Call Standard specifies that for returning large objects, the caller passes in a pointer in the x8 register, which points to the memory which will be populated by the result. However, it does not state that the function needs to preserve this register -- it remains a volatile reg, like the registers used to pass other arguments. Now, ABISysV_arm64 plugin implements "get the return value of a function call" functionality by reading the x8 register *after* the function returns, and decoding the memory it points to. This is wrong, as the register could be clobbered by that point. It happens to work for simple functions that don't do much, in most cases, but for example it fails if the compiler decides to copy the object into the destination via memcpy, and memcpy clobbers r8 (this happens with clang and some versions of android libc, at least). It's not really clear to me how this can be improved, but I'm filing this bug for posterity, and in case anyone has an idea. I guess it could be done if the caller specifies (via dwarf?) the memory it expects the result to be put in, but as far as I can tell, there is no such dwarf facility at the moment. In the mean time, I am going to disable the relevant checks in TestReturnValue for targets I know to be affected. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] llvm::to_integer
In the past I've advocated for use of StringRef::getAsInteger(). Sometimes this leads to awkward code, for example if you have a std::string you have to write StringRef(Str).getAsInteger(). Secondly, the return value is extremely confusing as it returns true on failure and false on success. I recently committed a function to llvm/ADT/StringExtras.h called to_integer which solves both of these problems. If you have a std::string S, you can call llvm::to_integer(S) and it just works. It also inverts the conditional so it now returns true on success and false on failure, which should be more intuitive. As a side benefit, the radix argument is also last instead of first, so it can take a default value. So you no longer have to pass 0 for the first argument to auto-detect. So I recommend using this function going forward. At some point in the future, I may even consider deleting getAsInteger() and all callers with this function. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
