[Lldb-commits] [PATCH] D92063: [LLDB] RegisterInfoPOSIX_arm64 remove unused bytes from g/G packet

2020-11-24 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid created this revision. omjavaid added a reviewer: labath. Herald added subscribers: kristof.beyls, emaste. omjavaid requested review of this revision. This came up while putting together our new strategy to create g/G packets where register offsets are calculated in increasing order of

[Lldb-commits] [PATCH] D91508: [LLDB/Lua] add support for one-liner breakpoint callback

2020-11-24 Thread Pedro Tammela via Phabricator via lldb-commits
tammela updated this revision to Diff 307440. tammela added a comment. Remove unnecessary wrappers/checks Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91508/new/ https://reviews.llvm.org/D91508 Files: lldb/bindings/lua/lua-swigsafecast.swig

[Lldb-commits] [PATCH] D91634: [lldb] Error when there are no ports to launch a gdbserver on

2020-11-24 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h:30 public: - using PortMap = std::map; using PacketHandler = Only the one in GDBRemoteCommunicationServerPlatform is/was used.

[Lldb-commits] [PATCH] D92035: [lldb] Use llvm::Optional for port in LaunchGDBServer

2020-11-24 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp:197 #endif - uint16_t *port_ptr = + uint16_t *port_ptr = port.getPointer(); if (m_socket_protocol == Socket::ProtocolTcp) { I

[Lldb-commits] [PATCH] D92035: [lldb] Use llvm::Optional for port in LaunchGDBServer

2020-11-24 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett created this revision. Herald added a project: LLDB. Herald added a subscriber: lldb-commits. DavidSpickett requested review of this revision. Herald added a subscriber: JDevlieghere. Previously we used UINT16_MAX to mean no port/no specifc port. This leads to confusion because

[Lldb-commits] [PATCH] D91634: [lldb] Error when there are no ports to launch a gdbserver on

2020-11-24 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett updated this revision to Diff 307356. DavidSpickett added a comment. Herald added a subscriber: mgorny. - Move PortMap into a class we can unittest - Use llvm::Expected for GetNextAvailablePort Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D91508: [LLDB/Lua] add support for one-liner breakpoint callback

2020-11-24 Thread Pedro Tammela via Phabricator via lldb-commits
tammela marked an inline comment as done. tammela added a comment. In D91508#2413582 , @labath wrote: > Right. That's why I'd like to have good wrappers, which make it easy to do > the right thing, and hard to do the wrong one. > > I don't think we're

[Lldb-commits] [PATCH] D91963: [lldb] [test/Register] Initial tests for regsets in core dumps [WIP]

2020-11-24 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. Come to think of it, given the number of core files you have amassed, it might not be unreasonable to turn this process into a shell script (in python, in shell with readelf+grep+dd, or whatever). Then we could check that in somewhere and ask people to run it whenever

[Lldb-commits] [PATCH] D91963: [lldb] [test/Register] Initial tests for regsets in core dumps [WIP]

2020-11-24 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. I can't tell the core sizes from the diff, but my recollection is that even non-freebsd core files are larger than one would like. Even with linux, ones has to go to great lengths to get it to create a small one. I'd recommend manually splicing the core to only include

[Lldb-commits] [PATCH] D91508: [LLDB/Lua] add support for one-liner breakpoint callback

2020-11-24 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. In D91508#2412510 , @tammela wrote: >> I'm not sure what you mean by that. Can you elaborate? > > Sure, it's was just a nod to your previous comment about that running > callbacks (C++ lambdas) inside a `pcall` is a dangerous API.