Re: [lldb-dev] Remote debugging ARM target from x86 host

This was marked as an lldb 5.0.0 release blocker since it's a regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183 lldb-dev: Is there any interest in fixing this bug? On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev wrote: > Hi, > > I am trying to remote debug ARM (linux) targe

Re: [lldb-dev] Forcing lldb to refresh process state

Perhaps a manual packet that tells your remote server that the next "s" packet is a reverse step, then run the lldb command "si". It would be simpler, from a packet log analysis standpoint, if you weren't stopped at a breakpoint location when you did this. -- Qualcomm Innovation Center,

Re: [lldb-dev] Forcing lldb to refresh process state

There is a standard for reverse stepping where the GDB remote protocol was extended to do the reverse stepping. See: https://sourceware.org/gdb/onlinedocs/gdb/Packets.html Look for "reverse" in the text. They added "bc" for reverse contin

Re: [lldb-dev] Remote debugging ARM target from x86 host

Port zero should never be returned as a valid port. We do bind to port zero just so we don't try and pick a port at random just to find it is being used. When we bind to port 9, we must find the actual port we bound to and return that. Seems something has gone wrong with the code that discovers

Re: [lldb-dev] Remote debugging ARM target from x86 host

What should be happening is Handle_qLaunchGDBServer calls LaunchGDBServer with a port of UINT16_MAX, which tells it to use a port in its port list. It shouldn't have a port list, so should return 0. LaunchGDBServer calls StartDebugServerProcess with a port of 0 in the url. StartDebugServerProce

Re: [lldb-dev] Forcing lldb to refresh process state

Yeah, this `bs` + `stepi` dance is the only workaround I found so far. On Wed, Aug 23, 2017 at 10:40 AM, Greg Clayton wrote: > There is a standard for reverse stepping where the GDB remote protocol was > extended to do the reverse stepping. See: > > https://sourceware.org/gdb/onlinedocs/gdb/Pack

Re: [lldb-dev] Forcing lldb to refresh process state

This isn't a work around right? You should be triggering your reverse step or reverse continue using a "process reverse-continue" or "thread reverse-step" right? If you do this, everything will just work. There should be no way this happens automagically without user interaction. Am I missing so

Re: [lldb-dev] Forcing lldb to refresh process state

On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton wrote: > This isn't a work around right? You should be triggering your reverse step > or reverse continue using a "process reverse-continue" or "thread > reverse-step" right? If you do this, everything will just work. There > should be no way this ha

[lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files

Hello, at least Fedora Linux distribution uses DWZ to reduce DWARF debug info size: https://fedoraproject.org/wiki/Features/DwarfCompressor It is DWARF optimization - not really a compression. One can find it by DW_TAG_partial_unit/DW_TAG_imported_unit: <0>: Abbrev Number: 103 (DW_TAG_p

Re: [lldb-dev] Forcing lldb to refresh process state

> On Aug 23, 2017, at 1:37 PM, Vadim Chugunov wrote: > > > On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton > wrote: > This isn't a work around right? You should be triggering your reverse step or > reverse continue using a "process reverse-continue" or "thread revers

Re: [lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files

> On Aug 23, 2017, at 2:06 PM, Jan Kratochvil via lldb-dev > wrote: > > Hello, > > at least Fedora Linux distribution uses DWZ to reduce DWARF debug info size: > https://fedoraproject.org/wiki/Features/DwarfCompressor > > It is DWARF optimization - not really a compression. One can fin