[lldb-dev] [Bug 48323] Attempting to redefine a variable fails silently

[via lldb-dev]

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

Raphael Isemann  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||teempe...@gmail.com

--- Comment #1 from Raphael Isemann  ---
Fixed in https://reviews.llvm.org/D89310

FWIW, the reason why I went with (i) is that it's technically not something one
can do in C/C++ (i.e., redefining a variable in the same scope). You can always
achieve (ii) by just assigning a new value to the existing $x.

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

[lldb-dev] Logging for multiple targets

[Tatyana Krasnukha via lldb-dev]

Hi lldb-dev,

Looking at a log produced by multiple targets I hardly can find out which 
message corresponds to which target. I find a way to distinct them, e.g. by 
prepending messages with "[target_id]". Putting an id to every message manually 
is not a choice obviously.

What do you think about having an optional target_id/execution_context inside 
the Log class or having an additional map with target-dependent logs? Maybe 
there are other options I missed?

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

Re: [lldb-dev] Logging for multiple targets

[Raphael “Teemperor” Isemann via lldb-dev]

Two problems that I can see:
* Log depends on no other part of LLDB. But nearly everything in LLDB depends 
on Log. So if we give Log a Target/ExeCtxt then all of LLDB would now depend on 
lldbTarget.
* IIRC our global log instance is shared between all debuggers/targets. So I'm 
not sure if adding a Target member would really help. We could make it a 
UID->Target map and pass down some target UID with each message, but then we 
might as well pass down a target itself. In both cases we would probably need 
to update all the logging code in LLDB.

The only solution that I can think of is having a Log wrapper class that 
prepends target information and we change all the GetLogIfAny/AllCategoriesSet 
that have a target in scope to call target.GetLogIfAllCategoriesSet (which 
would then return that Log wrapper). That wouldn't bring target ids to all log 
messages, but at least to all log messages that are aware of their target (and 
we would only need to update the `Log *log` initialisers but not all the 
LLDB_LOG statements itself).

Not sure if it's possible without hacks (like having a target ID in some TLS 
variable) to bring target ids to logging code that isn't aware of lldbTarget.

- Raphael


> On 30 Nov 2020, at 13:43, Tatyana Krasnukha via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
>  
> Looking at a log produced by multiple targets I hardly can find out which 
> message corresponds to which target. I find a way to distinct them, e.g. by 
> prepending messages with “[target_id]”. Putting an id to every message 
> manually is not a choice obviously.
>  
> What do you think about having an optional target_id/execution_context inside 
> the Log class or having an additional map with target-dependent logs? Maybe 
> there are other options I missed?
>  
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] How to disable GitHub Action notifications

[Tom Stellard via lldb-dev]

Hi,

We are currently working on a GitHub Action job to help with the 
transition to the 'main' branch.  As a result, if you make a commit, you 
may receive a notification about a failed GitHub Action.  If you want to 
disable these notifications, you can go to: 
https://github.com/settings/notifications and uncheck both the 'Email' 
and 'Web' boxes in the GitHub Actions section.  These settings are 
global, so they will affect all repositories you are watching.


Another way to disable these notifications would be to go to
https://github.com/watching and change the notification settings for 
llvm/llvm-project to 'Ignore'.  'Participating' and 'Custom' settings 
may also work, but I have not been able to verify this.


If you know of a better way to manage these notifications, please let me 
know.


Thanks,
Tom

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

[lldb-dev] [Bug 48342] New: LLDB crashes when inspecting an object created using ni::type_hierarchy

[via lldb-dev]

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

Bug ID: 48342
   Summary: LLDB crashes when inspecting an object created using
ni::type_hierarchy
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: hbu...@fender.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

When using the Native Instruments open source library matchine, the
ni::type_hierarchy objects crash the LLDB RPC Server when inspected using Xcode
12. 

Here is the issue filed against the matchine library:
https://github.com/NativeInstruments/matchine/issues/1

Here is an example that crashes LLDB. It requires the matchine library which
has a dependency on boost. 

```
#include 
#include 

struct EventBase {
EventBase() = default;
virtual ~EventBase() = default;
};

using Event = ni::type_hierarchy::from_base;

NI_SUB_TYPE(struct TestEvent, Event)
{
int value = 0;
TestEvent(int value_)
: value( value_ )
{
}
};

int main(int argc, const char * argv[]) {
TestEvent testEvent(100);

// insert breakpoint here to inspect testEvent
// inpecting testEvent will crash LLDB
TestEvent testEvent2(200);


return 0;
}
```

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