Re: [lldb-dev] Conditionally adding sources to the build

[Pavel Labath via lldb-dev]

The way we have done this with Linux native register contexts was to
notionally leave the files in the build, but completely #ifdef out their
contents (see NativeRegisterConextLinux_arm.cpp).
It's not very nice, but I think it's better than having six subfolders,
each with a single cpp file. If you'll need to group more than one file
this way, then maybe a subfolder would make more sense though.

pl

On 1 December 2016 at 00:30, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Unfortunately you will need to separate them at the directory levels.
>
> On Wed, Nov 30, 2016 at 4:29 PM Dmitry Mikulin via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> I’m trying to conditionally add source files to the lldb build based on a
>> cmake configure time variable. I get the following type of errors for all
>> sources not included in the build:
>>
>> CMake Error at cmake/modules/LLVMProcessSources.cmake:83 (message):
>>   Found unknown source file
>>   /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/
>> source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
>>
>>   Please update
>>   /homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/
>> source/Plugins/Process/FreeBSD/CMakeLists.txt
>>
>> Is there a way to work around/fix it or do I need to separate the files
>> at the directory level?
>>
>> Thanks.
>> Dmitry.
>>
>> ___
>> 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] Refactoring in LLDB Windows Plugin

[Pavel Labath via lldb-dev]

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 <
lldb-dev@lists.llvm.org> 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
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28055] continue in watchpoint commands disables the watchpoint

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=28055

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #1 from lab...@google.com ---
The test seems to pass now. Could it be due to our recent watchpoint changes?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Conditionally adding sources to the build

[Dmitry Mikulin via lldb-dev]

Thanks for the suggestions.
I’m working on native support for FreeBSD lldb-server, and wanted to have an 
option to build it both ways until it’s stable enough to replace current 
implementation. I’ll have it in a separate directory.


On Dec 1, 2016, at 2:55 AM, Pavel Labath 
mailto:lab...@google.com>> wrote:

The way we have done this with Linux native register contexts was to notionally 
leave the files in the build, but completely #ifdef out their contents (see 
NativeRegisterConextLinux_arm.cpp).
It's not very nice, but I think it's better than having six subfolders, each 
with a single cpp file. If you'll need to group more than one file this way, 
then maybe a subfolder would make more sense though.

pl

On 1 December 2016 at 00:30, Zachary Turner via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
Unfortunately you will need to separate them at the directory levels.

On Wed, Nov 30, 2016 at 4:29 PM Dmitry Mikulin via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
Hi,

I’m trying to conditionally add source files to the lldb build based on a cmake 
configure time variable. I get the following type of errors for all sources not 
included in the build:

CMake Error at cmake/modules/LLVMProcessSources.cmake:83 (message):
  Found unknown source file
  
/homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp

  Please update
  
/homes/dmitrym/buildspace/llvm-tot/llvm/tools/lldb/source/Plugins/Process/FreeBSD/CMakeLists.txt

Is there a way to work around/fix it or do I need to separate the files at the 
directory level?

Thanks.
Dmitry.

___
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