[lldb-dev] LLVM security group sync-up call

[Kristof Beyls via lldb-dev]

After the success of the LLVM security group round table at the virtual dev
meeting, we are organizing another sync-up call to progress topics related
to the LLVM security group .

This next sync-up call will take place on Tuesday the 16th of February, at
11am PST/7pm UTC/8pm CET.

I've started a Google doc to keep agenda topics, minutes and details on how
to join the call at
https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing

If you're interested in this, I hope to see you there!

Thanks,

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

[lldb-dev] LLVM 11.1.0-rc3 has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've tagged LLVM 11.1.0-rc3.  If there are no issues, then I'll be tagging
the final release in 1 week.  Testers please test and upload binaries.

-Tom

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

[lldb-dev] [Bug 48944] D89156 caused build failure on 11.0.1 for MacOS target

[via lldb-dev]

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

a...@mozilla.com changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from a...@mozilla.com ---
Fix submitted
https://reviews.llvm.org/rG1fdec59bffc11ae37eb51a1b9869f0696bfd5312

-- 
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

Re: [lldb-dev] Help fixing deadlock in DWARF symbol preloading

[Greg Clayton via lldb-dev]

A simpler solution is to remove the lock in Module::GetDescription(...) all of 
the data that is used to dump the module description is set correctly (the 
file, the arch and the object name for BSD archives)) very early on when a 
module is created before anyone should be making symbol or debug info queries 
or parsing.


> On Feb 5, 2021, at 1:24 PM, Jorge Gorbe Moya via lldb-dev 
>  wrote:
> 
> I just started looking at how to do this (having a separate mutex for the 
> description) and I think I found another bug. Or maybe I'm missing some 
> assumption.
> 
> On one hand, Module::SetArchitecture won't assign the new value if m_arch is 
> already valid, just return m_arch.IsCompatibleWith(new_arch). On the other 
> hand, in Module::MergeArchitecture we have both code that assumes that 
> SetArchitecture replaces the previous value:
> 
>   if (!m_arch 
> .IsCompatibleMatch
>  
> (arch_spec
>  
> ))
>  {
> // The new architecture is different, we just need to replace it.
> return SetArchitecture 
> (arch_spec
>  
> );
>   }
> 
> and right after it we have code that works around the fact that 
> SetArchitecture doesn't replace the previous value sometimes
> 
>   // Merge bits from arch_spec into "merged_arch" and set our architecture.
>   ArchSpec 
> 
>  merged_arch 
> (m_arch
>  
> );
>   merged_arch 
> .MergeFrom
>  
> (arch_spec
>  
> );
>   // SetArchitecture() is a no-op if m_arch is already valid.
>   m_arch 
> 
>  = 
> 
>  ArchSpec 
> ();
>   return SetArchitecture 
> (merged_arch
>  
> );
> 
> My guess is that the first of the snippets above has a bug (it intends to 
> replace the architecture but doesn't) and that replacing a module's 
> architecture with an incompatible one is something that doesn't happen often 
> and the bug went unnoticed. Does this make sense?
> 
> On Thu, Feb 4, 2021 at 5:38 PM Raphael Isemann