Re: [lldb-dev] Difficulty in using target.source-map to map source files

[Jim Ingham via lldb-dev]

> On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev 
>  wrote:
> 
> Hi All,
> 
> Below is a sample example, where target.source-map seems to have a 
> limitation. The limitation seems to be because 
> 1. lldb does not have an equivalent command like directory in gdb

The gdb "dir" command seemed always to be more annoying than useful in real 
situations.  If your project had any complexity in the directory structure you 
ended up having to add dir commands for all the subdirectories, which got 
tedious quickly.  Since you pretty much always move your sources around 
rigidly, "source maps" are a more natural way to specify this.

Note, we could add a recursive "dir" command, but you can't do the simpleminded 
recursive search or you'll mess up when the sources have same named files in 
different directories.  Because of this, again the source maps seem more suited.

> 2. target.source-map does not accept multiple mapping entries. I checked this 
> only with freebsd.
> 
> (lldb) settings show target.source-map
> target.source-map (path-map) =
> [0] "/home/karnajitw/lldb_test_execs/test_source_line1" -> 
> "/u/test/test_source_line1"

That is not correct:

(lldb) settings set target.source-map /some/source/path /tmp 
/some/other/source/path /tmp
(lldb) settings show target.source-map
target.source-map (path-map) =
[0] "/some/source/path" -> "/tmp"
[1] "/some/other/source/path" -> "/tmp"

or

(lldb) set set target.source-map /some/source/path /tmp
(lldb) set append target.source-map /some/other/source/path /tmp
(lldb) set show target.source-map
target.source-map (path-map) =
[0] "/some/source/path" -> "/tmp"
[1] "/some/other/source/path" -> "/tmp"


> 
> 3. Haven't checked in the code yet, but if we see the mappings of scenario 1, 
> they all point to a single real path 
> /home/karnajitw/lldb_test_execs/test_source_line1. But looks like the mapping 
> logic only considers strings into account. But, at the same time, I am not 
> claiming that they should be interpreted as path from a different machine 
> during the mapping.
> 

I'm not sure what you mean here.  lldb does what it can to unwind the source 
path, but it doesn't assume that those paths actually exist locally, so the 
most it can do is remove redundant "/"-s and "/./"-s and unwind ".."-s.  We do 
this before most source path comparisons (it's part of the FileSpec Equals 
method).  We've been tinkering with this over time so make sure you are using a 
recent version of lldb.  If there are places where we don't do this, then 
that's easily fixed.


> I want to check on this issue in-depth. But before that, want to confirm if 
> this is real issue or there are other ways to deal these scenarios which I am 
> not aware of?
> 
> I am referring below link for the lldb commands.
> https://lldb.llvm.org/lldb-gdb.html
> 
> 1. First scenario: Different souce file path representation
> 
> [/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g 
> /home/karnajitw/lldb_test_execs///test_source_line1/main.c 
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c 
> /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> 
> Machine 1: /home/karnajitw/lldb_test_execs/test_source_line1 -> Machine 2: 
> /u/test/test_source_line1
> 
> test_source_line1
> |-- a
> |   |-- ainc.c
> |   |-- ainc.h
> |   `-- b
> |   |-- binc.c
> |   `-- binc.h
> |-- a.out
> `-- main.c
> 
> % ./lldb test_source_line1/a.out
> 
> (lldb) target create "test_source_line1/a.out"
> Current executable set to 'test_source_line1/a.out' (x86_64).
> (lldb) l main
> File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> (lldb) l afn
> File: 
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
> (lldb) l bfn
> File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> 
> (lldb) settings set target.source-map 
> /home/karnajitw/lldb_test_execs///test_source_line1 /u/test/test_source_line1
> 
> (lldb) l main
> File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
>1#include "a/ainc.h"
>2
>3int main()
>4{
>5  afn();
>6
>7  bfn();
>8
>9  return 0;
>10   }
> (lldb) l afn
> File: 
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
> (lldb) l bfn
> File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> 
> (lldb) settings set target.source-map 
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1 
> /u/test/test_source_line1
> 
> (lldb) l main
> File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> (lldb) l afn
> File: 
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
>1#include 
>2#include "ainc.h"
>3
>4void afn()
>5{
>6  printf("Hello this is afn...\n");
>7}
> (lldb) l bfn
> File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> 
> (lldb) settings set targ

Re: [lldb-dev] [llvm-dev] [5.0.0 Release] Please help fix the remaining blockers (2 days left!)

[Kamil Rytarowski via lldb-dev]

On 22.08.2017 01:36, Hans Wennborg via llvm-dev wrote:
> Hello everyone,
> 
> According to the release schedule, we're supposed to be tagging
> 'final' on Wednesday. Unfortunately, I suspect we will be a little
> late.
> 
> There are currently 32 open release blockers:
> https://bugs.llvm.org/buglist.cgi?f1=blocked&o1=equals&v1=33849&query_format=advanced&resolution=---
> 
> Some of those have traction, but many don't. Some just need bisection,
> checking if the issue still reproduces, etc.
> 
> Please help take a look at the bugs in that list. It would be really
> great if we could drive it down to zero blockers and tag rc3 by the
> end of the week.
> 

It would be nice to backport this patch as is to 5.0.0.

"Use sys::Memory::AllocateRWX for JIT code"
https://reviews.llvm.org/D35558

It JIT unbreaks code for NetBSD-8.x.

A proper solution, to revamp the JIT code, with a better API is under
development and should land LLVM-6.0.0.

> Many thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 




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] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

It does send '$T05...' in response, but it looks like lldb does not analyze
responses to manually sent packets.

On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton  wrote:

> If you do a reverse step it actually should send a process resumed and a
> process stopped event.
>
> > On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev 
> wrote:
> >
> > I'm trying to reverse-step.  So I think I'd need to refresh all thread
> states?
> >
> >> On Aug 18, 2017, at 4:50 PM, Jim Ingham  wrote:
> >>
> >> No, there hasn't been a need for this.
> >>
> >> What commands are you planning to send?  Or equivalently, how much
> state are you expecting to change?
> >>
> >> Jim
> >>
> >>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>
> >>> Hi,
> >>> Is there any way to force lldb to refresh it's internal record of
> debuggee process state (as if it had just received a stop event)?  I want
> to send a custom command to remote gdb process stub (via `process plugin
> packet send`).  This works, but if the command alters debuggee state, lldb
> won't know about it.
> >>> ___
> >>> 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
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [5.0.0 Release] Please help fix the remaining blockers (2 days left!)

[Hans Wennborg via lldb-dev]

On Tue, Aug 22, 2017 at 1:20 PM, Kamil Rytarowski  wrote:
> On 22.08.2017 01:36, Hans Wennborg via llvm-dev wrote:
>> Hello everyone,
>>
>> According to the release schedule, we're supposed to be tagging
>> 'final' on Wednesday. Unfortunately, I suspect we will be a little
>> late.
>>
>> There are currently 32 open release blockers:
>> https://bugs.llvm.org/buglist.cgi?f1=blocked&o1=equals&v1=33849&query_format=advanced&resolution=---
>>
>> Some of those have traction, but many don't. Some just need bisection,
>> checking if the issue still reproduces, etc.
>>
>> Please help take a look at the bugs in that list. It would be really
>> great if we could drive it down to zero blockers and tag rc3 by the
>> end of the week.
>>
>
> It would be nice to backport this patch as is to 5.0.0.
>
> "Use sys::Memory::AllocateRWX for JIT code"
> https://reviews.llvm.org/D35558
>
> It JIT unbreaks code for NetBSD-8.x.
>
> A proper solution, to revamp the JIT code, with a better API is under
> development and should land LLVM-6.0.0.

It sounds like the review is stuck though. I'd rather not block on it.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Greg Clayton via lldb-dev]

You need to send some sort of continue through the GDB remote interface. The 
only way to get a $T packet back is in response to a "?" packet or to a "vCont" 
or other continue or step packet.

> On Aug 22, 2017, at 2:30 PM, Vadim Chugunov  wrote:
> 
> It does send '$T05...' in response, but it looks like lldb does not analyze 
> responses to manually sent packets.
> 
> On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton  > wrote:
> If you do a reverse step it actually should send a process resumed and a 
> process stopped event.
> 
> > On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev  > > wrote:
> >
> > I'm trying to reverse-step.  So I think I'd need to refresh all thread 
> > states?
> >
> >> On Aug 18, 2017, at 4:50 PM, Jim Ingham  >> > wrote:
> >>
> >> No, there hasn't been a need for this.
> >>
> >> What commands are you planning to send?  Or equivalently, how much state 
> >> are you expecting to change?
> >>
> >> Jim
> >>
> >>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev 
> >>> mailto:lldb-dev@lists.llvm.org>> wrote:
> >>>
> >>> Hi,
> >>> Is there any way to force lldb to refresh it's internal record of 
> >>> debuggee process state (as if it had just received a stop event)?  I want 
> >>> to send a custom command to remote gdb process stub (via `process plugin 
> >>> packet send`).  This works, but if the command alters debuggee state, 
> >>> lldb won't know about it.
> >>> ___
> >>> 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 
> > 
> 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev