Re: [lldb-dev] Refactoring in LLDB Windows Plugin
For what it's worth, we've been using lldb with ds2 to do remote debugging on Windows (x86) and Windows Phone (arm) and the lldb side of things works well with remote Windows targets. Besides porting lldb-server to Windows there shouldn't be any extra effort on the lldb side to do what Greg is talking about. On Wed, Nov 30, 2016 at 9:35 AM, Greg Clayton via lldb-dev wrote: > >> On Nov 29, 2016, at 10:16 PM, Zachary Turner wrote: >> >> What would it take to make it so that local and remote process plugins use >> the same exact interface? I mean in theory they're doing the same thing, >> just on a different machine. If they shared an identical interface then you >> could hook the lldb-server up to it and it would work either locally or >> remotely. >> >> What was the original motivation for having the api design of remote and >> local process plugins diverge? > > The plan was always do remote so we are always using one thing. We started > off thinking we wanted to have a native plug-in and a remote GDB server, but > when we found we didn't have serious performance issues we went the > lldb-server/debugserver route for everything on our end. lldb-server uses > NativeProcess and NativeThread as base classes that must be subclassed and we > would make a ProcessNative plug-in that used the native compiled version of > these (like lldb-server does), but then we have two code paths to test: > native and remote. So we either have to run twice the number of tests, one > local and one remote, so we can make sure native and remote work correctly, > or we just go one route. What would tend to happen is we would 99.9% of > people would do local debugging only and all bugs submitted would mostly be > bugs with the native implementation and remote would suffer and become > neglected. GDB had two different code paths for these so remote really did > suffer and we evolved to use remote only on all our systems. Another nice > reason for this is you can save the GDB remote packet log traffic when you do > encounter a bug and see exactly what happened when a bug happened. > > So due to history, we started thinking we would need both native and remote > plug-ins, but we migrated over time to just one solution for simpler testing, > ensuring remote debugging is rock solid since it is always used for local > debugging, and for the convenience of being able to completely lop all > traffic to/from the process with the GDB remote logs. > > Greg > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Refactoring in LLDB Windows Plugin
Yeah, we have to fake the numbers, we have some sort of dummy mapping that converts Windows events to the UNIX equivalent that makes the most sense. It's kind of dumb, but that's the only thing that LLDB or gdb support. First half of the conversion is here: https://github.com/facebook/ds2/blob/master/Sources/Target/Windows/Thread.cpp#L110 and the second half is here: https://github.com/facebook/ds2/blob/master/Sources/GDBRemote/Structures.cpp#L357 On Thu, Dec 1, 2016 at 3:00 AM, Pavel Labath wrote: > I'm curious, can you share how did you deal with the fact that the > gdb-remote protocol is very signal-centric? E.g. every stop-reply ($T) has > to have a specific signal associated with it, and some signals have special > meaning in lldb. Do you just fake the signal numbers when you need to? Or is > the situation not as bad as I imagine? > > cheers, > pl > > On 1 December 2016 at 07:57, Stephane Sezer via lldb-dev > wrote: >> >> For what it's worth, we've been using lldb with ds2 to do remote >> debugging on Windows (x86) and Windows Phone (arm) and the lldb side >> of things works well with remote Windows targets. Besides porting >> lldb-server to Windows there shouldn't be any extra effort on the lldb >> side to do what Greg is talking about. >> >> On Wed, Nov 30, 2016 at 9:35 AM, Greg Clayton via lldb-dev >> wrote: >> > >> >> On Nov 29, 2016, at 10:16 PM, Zachary Turner >> >> wrote: >> >> >> >> What would it take to make it so that local and remote process plugins >> >> use the same exact interface? I mean in theory they're doing the same >> >> thing, just on a different machine. If they shared an identical interface >> >> then you could hook the lldb-server up to it and it would work either >> >> locally or remotely. >> >> >> >> What was the original motivation for having the api design of remote >> >> and local process plugins diverge? >> > >> > The plan was always do remote so we are always using one thing. We >> > started off thinking we wanted to have a native plug-in and a remote GDB >> > server, but when we found we didn't have serious performance issues we went >> > the lldb-server/debugserver route for everything on our end. lldb-server >> > uses NativeProcess and NativeThread as base classes that must be subclassed >> > and we would make a ProcessNative plug-in that used the native compiled >> > version of these (like lldb-server does), but then we have two code paths >> > to >> > test: native and remote. So we either have to run twice the number of >> > tests, >> > one local and one remote, so we can make sure native and remote work >> > correctly, or we just go one route. What would tend to happen is we would >> > 99.9% of people would do local debugging only and all bugs submitted would >> > mostly be bugs with the native implementation and remote would suffer and >> > become neglected. GDB had two different code paths for these so remote >> > really did suffer and we evolved to use remote only on all our systems. >> > Another nice reason for this is you can save the GDB remote packet log >> > traffic when you do encounter a bug and see exactly what happened when a >> > bug >> > happened. >> > >> > So due to history, we started thinking we would need both native and >> > remote plug-ins, but we migrated over time to just one solution for simpler >> > testing, ensuring remote debugging is rock solid since it is always used >> > for >> > local debugging, and for the convenience of being able to completely lop >> > all >> > traffic to/from the process with the GDB remote logs. >> > >> > Greg >> > >> > ___ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> >> >> -- >> Stephane Sezer >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Support for Error Strings in remote protocol
What's the specific use case that you're trying to support with error messages in the protocol? My initial thought on this is that it's not really the debug server's job to generate human-readable error messages and that the debugger is better suited to do the job. Can this problem be solved by extending the current integer list used for errors? On Wed, Jun 21, 2017 at 8:31 AM Ravitheja Addepally via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello all, >Currently the remote protocol in LLDB does not allow sending Error > Strings in response to remote packets, it only allows for "ENN" format > where N is a hex integer. In our current ongoing work, we would like to > have support for Sending Error Strings from lldb-server. I would like to > invite any opinions or suggestions in this matter ? > > A very simple proposal would be to just attach an error string maybe as a > Name:Value Pair ? like so -> > > EXX;"Error String" > or > EXX;M"Error String" > > I guess removing EXX would make it incompatible with gdb-server. Also > adding new packets to query errors might not be desired ? > > > Regards, > A Ravi Theja > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Support for Error Strings in remote protocol
True, but the error strings would be only available with lldb-server as well. Keeping a common table of error numbers seems like a good solution. On Wed, Jun 21, 2017 at 4:33 PM Jim Ingham wrote: > Because the gdb remote protocol docs explicitly state: > > The error response returned for some packets includes a two character > error number. That number is not well defined. > > we don't put much stock in the actual error numbers. > > If you can determine that you are talking to lldb-server, then we could > actually make these meaningful by keeping a common table. But that would > only work for lldbserver. > > Jim > > > > On Jun 21, 2017, at 4:18 PM, Stephane Sezer via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > What's the specific use case that you're trying to support with error > messages in the protocol? My initial thought on this is that it's not > really the debug server's job to generate human-readable error messages and > that the debugger is better suited to do the job. > > > > Can this problem be solved by extending the current integer list used > for errors? > > > > On Wed, Jun 21, 2017 at 8:31 AM Ravitheja Addepally via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hello all, > >Currently the remote protocol in LLDB does not allow sending > Error Strings in response to remote packets, it only allows for "ENN" > format where N is a hex integer. In our current ongoing work, we would like > to have support for Sending Error Strings from lldb-server. I would like to > invite any opinions or suggestions in this matter ? > > > > A very simple proposal would be to just attach an error string maybe as > a Name:Value Pair ? like so -> > > > > EXX;"Error String" > > or > > EXX;M"Error String" > > > > I guess removing EXX would make it incompatible with gdb-server. Also > adding new packets to query errors might not be desired ? > > > > > > Regards, > > A Ravi Theja > > > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- > > -- > > Stephane Sezer > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] environment vars not passed through to linux targets
Which set of env vars did you want the child process to inherit? The env vars of the platform process on the remote? On Wed, Jul 5, 2017 at 8:47 AM Christopher Book via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, I'm remote debugging to linux (platform select remote-linux), and then > launching a process on the target. > > file > > process launch -w /some/dir > > When I do this, the process is launched but it gets an empty list of > environment variables. I've confirmed that lldb and the gdb server both > have the vars, but not the target process. > > I can manually pass environment variables to the target using the > '--environment' flag, and this works. But in general I need these to be > inherited. > > Based on online comments about this working on mac, this appears to be a > linux-specific bug? Is this expected or known? > > Thanks, > Chris Book > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Status of x86_64-pc-windows-msvc target + DWARF debugging
Can confirm, x86_64 Windows debugging with DWARF works. We use it to debug some fairly large binaries in production. On Thu, Nov 2, 2017 at 2:07 PM Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello, > > I think it mostly works. i686-pc-windows-msvc + DWARF should definitely > work for basic things. x64 was never heavily tested simply due to it not > being my primary build configuration. I think all the hooks are in place, > so in theory it might work. If something's wrong I expect it won't be more > than a couple of lines of code to fix. > > On Thu, Nov 2, 2017 at 2:15 AM kyra via lldb-dev > wrote: > >> Hi, >> >> The information on LLDB web page looks outdated, hence I've decided to >> ask the list. >> >> Is LLDB able to (perhaps, very basically) debug x86_64-pc-windows-msvc + >> DWARF debugging info code? >> >> If it is, then which LLDB build configuration is the least problematic >> to use? >> >> Cheers, >> Kyra >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD
I had that issue a while back and uploaded a few diffs that fix the problem, but never landed them. I don't remember exactly what needed to change, but you can view them here: https://reviews.llvm.org/D40538 https://reviews.llvm.org/D40537 Let me know if you want to help get them committed to the tree. On Wed, Jun 20, 2018 at 8:05 AM Scott Funkenhauser via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hey guys, > > LLDB uses source/Utility/UUID.cpp to store the build ID. This class only > supports 16 or 20 byte IDs. > > When parsing the .note.gnu.build-id ELF section, any build ID between 4 > and 20 bytes will be parsed and saved (which will silently fail if the size > isn't 16 or 20 bytes) > https://github.com/llvm-mirror/lldb/blob/4dc18b8ce3f95c2aa33edc4c821909c329e94be9/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1279 > . > > I discovered this issue because by default LLD will generate a 8 byte > build ID, causing LLDB to ignore the .note.gnu.build-id ELF section and > compute a crc32 at runtime. > > Is this a know issue that somebody is already working on? (After a quick > search I couldn't find any open bugs with a similar description). > > Does anybody have any objection to modifying UUID::SetBytes to accept any > byte array with a size between 4 - 20 bytes, and pad with zeros to the next > largest supported size (either 16 or 20 bytes). > > ex. > Setting a UUID with length of 8, would pad with 8 trailing zeros to have > an overall length of 16. > Setting a UUID with length of 17, would pad with 3 trailing zeros to have > an overall length of 20. > > Thanks, > Scott > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- -- Stephane Sezer ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
