main

Yyuanchao1feat: add cjthread api

a05bd00a创建于 5月14日历史提交

文件	最后提交记录	最后更新时间
interface	feat: add cjthread api Signed-off-by: yuanchao <yuanchao55@h-partners.com>	1 个月前
lua	[lldb] (Semi-automatically) format .swig files I've found my recent ventures into the swig land painful because of the strange way they are formatted. This patch attempts to alleviate future headaches by formatting these files into something resembling the normal llvm style. Unfortunately, completely formatting these files automatically does not work because clang format gets confused by swigs % syntax, so I have employed a hybrid approach where I formatted blocks of c++ code with clang-format and then manually massaged the code until it looked reasonable (and compiled). I don't expect these files to remain perfectly formatted (although, if one's editor is configured to configure the current line/block on request, one can get pretty good results by using it judiciously), but at least it will prevent the (mangled form of the) old lldb style being proliferated endlessly. Differential Revision: https://reviews.llvm.org/D115736	4 年前
python	feat: 930 opensource Signed-off-by: wzy_00889928 <1322947566@qq.com>	8 个月前
CMakeLists.txt	[lldb] Move create_relative_symlink function up in CMake hierarchy Configuring lldb with LLDB_ENABLE_PYTHON=OFF and LLDB_ENABLE_LUA=ON results in a CMake error: CMake Error at lldb/bindings/lua/CMakeLists.txt:47 (create_relative_symlink): Unknown CMake command "create_relative_symlink". Call Stack (most recent call first): lldb/CMakeLists.txt:117 (finish_swig_lua) This is because the CMake function create_relative_symlink only exists in lldb/bindings/python/CMakeLists.txt, and not in lldb/bindings/lua/CMakeLists.txt. Move the function to lldb/bindings/CMakeLists.txt, so it is available for all language bindings. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D114465	4 年前
headers.swig	feat: merge dev to main Signed-off-by: yuanchao <yuanchao55@h-partners.com>	1 个月前
interfaces.swig	feat: merge dev to main Signed-off-by: yuanchao <yuanchao55@h-partners.com>	1 个月前
macros.swig	[lldb][bindings] Implement __repr__ instead of __str__ When using the script Python repl, SB objects are printed in a way that gives the user no information. The simplest example is: (lldb) script lldb.debugger <lldb.SBDebugger; proxy of <Swig Object of type 'lldb::SBDebugger *' at 0x1097a5de0> > This output comes from the Python repl printing the repr() of an object. None of the SB classes implement __repr__, and all print like the above. However, many (most?, all?) SB classes implement __str__. Because they implement __str__, a more detailed output can be had by printing the object, for example: (lldb) script print(lldb.debugger) Debugger (instance: "debugger_1", id: 1) For convenience, this change switches all SB classes that implement to __str__ to instead implement __repr__. **The result is that str() and repr() will produce the same output**. This is because str calls __repr__ for classes that have no __str__ method. The benefit being that when writing a script invocation, you don't need to remember to wrap in print(). If that isn't enough motivation, consider the case where your Python expression results in a list of SB objects, in that case you'd have to map or use a list comprehension like [str(x) for x in <expr>] in order to see the details of the objects in the list. For reference, the docs for repr say: > repr(object) > Return a string containing a printable representation of an object. For > many types, this function makes an attempt to return a string that would > yield an object with the same value when passed to eval(); otherwise, the > representation is a string enclosed in angle brackets that contains the > name of the type of the object together with additional information often > including the name and address of the object. A class can control what this > function returns for its instances by defining a __repr__() method. and the docs for __repr__ say: > object.__repr__(self) > Called by the repr() built-in function to compute the “official” string > representation of an object. If at all possible, this should look like a > valid Python expression that could be used to recreate an object with the > same value (given an appropriate environment). If this is not possible, a > string of the form <...some useful description...> should be returned. The > return value must be a string object. If a class defines __repr__() but not > __str__(), then __repr__() is also used when an “informal” string > representation of instances of that class is required. > > This is typically used for debugging, so it is important that the > representation is information-rich and unambiguous. Even if it were convenient to construct Python expressions for SB classes so that they could be eval'd, however for typical lldb usage, I can't think of a motivating reason to do so. As it stands, the only action the docs say to do, that this change doesn't do, is wrap the repr string in <> angle brackets. An alternative implementation is to change lldb's python repl to apply str() to the top level result. While this would work well in the case of a single SB object, it doesn't work for a list of SB objects, since str([x]) uses repr to convert each list element to a string. Differential Revision: https://reviews.llvm.org/D127458	3 年前