[Lldb-commits] [lldb] [lldb] Remove dead code block (NFC) (PR #94775)

2024-06-15 Thread Florian Mayer via lldb-commits 

fmayer wrote:

Random drive-by:

> The check that max_bit_pos == sign_bit_pos conflicts with the check that 
> sign_bit_pos < max_bit_pos in the block surrounding it.

Should we add an `assert` to this function then?

https://github.com/llvm/llvm-project/pull/94775
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

2024-06-17 Thread Florian Mayer via lldb-commits 


@@ -745,26 +745,25 @@ Status Scalar::SetValueFromData(const DataExtractor &data,
 
 bool Scalar::SignExtend(uint32_t sign_bit_pos) {
   const uint32_t max_bit_pos = GetByteSize() * 8;
+  assert(sign_bit_pos < max_bit_pos);
 
-  if (sign_bit_pos < max_bit_pos) {
-switch (m_type) {
-case Scalar::e_void:
-case Scalar::e_float:
-  return false;
+  switch (m_type) {

fmayer wrote:

isn't this whole thing now

```
if (m_type  != Scalar::e_int || sign_bit_pos >= max_bit_pos - 1)
  return false;

[...]


https://github.com/llvm/llvm-project/pull/95678
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

2024-06-17 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer edited https://github.com/llvm/llvm-project/pull/95678
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

2024-06-17 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer edited https://github.com/llvm/llvm-project/pull/95678
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

2024-06-20 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/95678
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [compiler-rt] [mlir] [llvm] [sanitizer] Pre-commit disabled test for fork (PR #75257)

2023-12-12 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer edited https://github.com/llvm/llvm-project/pull/75257
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [mlir] [llvm] [compiler-rt] [lldb] [sanitizer] Pre-commit disabled test for fork (PR #75257)

2023-12-12 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer approved this pull request.


https://github.com/llvm/llvm-project/pull/75257
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] [compiler-rt] [mlir] [sanitizer] Pre-commit disabled test for fork (PR #75257)

2023-12-12 Thread Florian Mayer via lldb-commits 




fmayer wrote:

would appreciate a short comment that explains what this test does in an 
abstract sense, like

"sets up memory like so and so and verifies that this and this doesn't happen"

https://github.com/llvm/llvm-project/pull/75257
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [compiler-rt] [mlir] [llvm] [lldb] [sanitizer] Pre-commit disabled test for fork (PR #75257)

2023-12-12 Thread Florian Mayer via lldb-commits 


@@ -18,10 +18,10 @@
 
 static const size_t kBufferSize = 1 << 20;
 
-static void *background(void *arg) { return nullptr; }
-
 pthread_barrier_t bar;
 
+// Without appropriate workarounds this code can cause the forked process to
+// start with locked internal mutexes.

fmayer wrote:

optional nit: call it `ShouldNotDeadlock`?

https://github.com/llvm/llvm-project/pull/75257
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [llvm] [lldb] [mlir] [libc] [compiler-rt] [flang] [clang] [openmp] [hwasan] Respect strip_path_prefix printing locals (PR #76132)

2023-12-21 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer approved this pull request.

Lgtm thanks

https://github.com/llvm/llvm-project/pull/76132
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [llvm] [libcxx] [lldb] [flang] [openmp] [mlir] [libc] [compiler-rt] [hwasan] Classify stack overflow, and use after scope (PR #76133)

2023-12-21 Thread Florian Mayer via lldb-commits 


@@ -221,29 +221,55 @@ static void PrintStackAllocations(const 
StackAllocationsRingBuffer *sa,
   for (LocalInfo &local : frame.locals) {
 if (!local.has_frame_offset || !local.has_size || 
!local.has_tag_offset)
   continue;
+if (!(local.name && internal_strlen(local.name)) &&
+!(local.function_name && internal_strlen(local.name)) &&
+!(local.decl_file && internal_strlen(local.decl_file)))
+  continue;
 tag_t obj_tag = base_tag ^ local.tag_offset;
 if (obj_tag != addr_tag)
   continue;
-// Calculate the offset from the object address to the faulting
-// address. Because we only store bits 4-19 of FP (bits 0-3 are
-// guaranteed to be zero), the calculation is performed mod 2^20 and 
may
-// harmlessly underflow if the address mod 2^20 is below the object
-// address.
-uptr obj_offset =
-(untagged_addr - fp - local.frame_offset) & (kRecordFPModulus - 1);
-if (obj_offset >= local.size)
-  continue;
+uptr local_beg = (fp + local.frame_offset) |
+ (untagged_addr & ~(uptr(kRecordFPModulus) - 1));
+uptr local_end = local_beg + local.size;
+
 if (!found_local) {
   Printf("\nPotentially referenced stack objects:\n");
   found_local = true;
 }
+
+uptr offset;
+const char *whence;
+const char *cause;
+if (local_beg <= untagged_addr && untagged_addr < local_end) {
+  offset = untagged_addr - local_beg;
+  whence = "inside";
+  cause = "use-after-scope";
+} else if (untagged_addr >= local_end) {
+  offset = untagged_addr - local_end;
+  whence = "after";
+  cause = "stack-buffer-overflow";
+} else {
+  offset = local_beg - untagged_addr;
+  whence = "before";
+  cause = "stack-buffer-overflow";
+}
+Decorator d;
+Printf("%s", d.Error());
+Printf("Cause: %s\n", cause);
+Printf("%s", d.Default());
+Printf("%s", d.Location());
+Printf("%p is located %zd bytes %s a %zd-byte region [%p,%p)\n",
+   untagged_addr, offset, whence, local_end - local_beg, local_beg,
+   local_end);
+Printf("%s", d.Allocation());
 StackTracePrinter::GetOrInit()->RenderSourceLocation(

fmayer wrote:

FYI the offline symbolizer has this output format

```
self.print('')
self.print('Potentially referenced stack object:')
self.print('  %d bytes inside a variable "%s" in stack frame of 
function "%s"' % (obj_offset, local[2], local[0]))
self.print('  at %s' % (local[1],))
```

https://github.com/llvm/llvm-project/pull/76133
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [llvm] [openmp] [libc] [compiler-rt] [lldb] [mlir] [flang] [libcxx] [clang] [hwasan] Classify stack overflow, and use after scope (PR #76133)

2023-12-21 Thread Florian Mayer via lldb-commits 


@@ -221,29 +221,55 @@ static void PrintStackAllocations(const 
StackAllocationsRingBuffer *sa,
   for (LocalInfo &local : frame.locals) {
 if (!local.has_frame_offset || !local.has_size || 
!local.has_tag_offset)
   continue;
+if (!(local.name && internal_strlen(local.name)) &&
+!(local.function_name && internal_strlen(local.name)) &&
+!(local.decl_file && internal_strlen(local.decl_file)))
+  continue;
 tag_t obj_tag = base_tag ^ local.tag_offset;
 if (obj_tag != addr_tag)
   continue;
-// Calculate the offset from the object address to the faulting
-// address. Because we only store bits 4-19 of FP (bits 0-3 are
-// guaranteed to be zero), the calculation is performed mod 2^20 and 
may
-// harmlessly underflow if the address mod 2^20 is below the object
-// address.
-uptr obj_offset =
-(untagged_addr - fp - local.frame_offset) & (kRecordFPModulus - 1);
-if (obj_offset >= local.size)
-  continue;
+uptr local_beg = (fp + local.frame_offset) |

fmayer wrote:

 I am confused by this. Could you add a comment as on the LHS? Why isn't the 
`local_beg` not just `fp + local.frame_offset`?

https://github.com/llvm/llvm-project/pull/76133
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [llvm] [openmp] [libc] [compiler-rt] [lldb] [mlir] [flang] [libcxx] [clang] [hwasan] Classify stack overflow, and use after scope (PR #76133)

2023-12-21 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer commented:

Remove this comment?

Line 780

```
// TODO(fmayer): figure out how to distinguish use-after-return and
// stack-buffer-overflow.
```

https://github.com/llvm/llvm-project/pull/76133
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libc] [clang] [openmp] [flang] [libcxx] [llvm] [compiler-rt] [lldb] [mlir] [hwasan] Classify stack overflow, and use after scope (PR #76133)

2023-12-21 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer approved this pull request.


https://github.com/llvm/llvm-project/pull/76133
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (PR #84219)

2024-03-08 Thread Florian Mayer via lldb-commits 

fmayer wrote:

I think this broke the build completely?

```
/usr/local/google/home/fmayer/large/llvm-project/lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc64.cpp:771:14:
 error: no viable conversion from 'llvm::Expected' (aka 
'Expected') to 'uint32_t' (aka 'unsigned int')
uint32_t n = m_type.GetNumChildren(omit_empty_base_classes, nullptr);
 ^   ~~~
```

https://github.com/llvm/llvm-project/pull/84219
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 300a39b - Revert "Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)"

2024-03-08 Thread Florian Mayer via lldb-commits 

Author: Florian Mayer
Date: 2024-03-08T12:14:22-08:00
New Revision: 300a39bdad4593fdc2618eb28f6e838df735619a

URL: 
https://github.com/llvm/llvm-project/commit/300a39bdad4593fdc2618eb28f6e838df735619a
DIFF: 
https://github.com/llvm/llvm-project/commit/300a39bdad4593fdc2618eb28f6e838df735619a.diff

LOG: Revert "Change GetNumChildren()/CalculateNumChildren() methods return 
llvm::Expected (#84219)"

This reverts commit 99118c809367d518ffe4de60c16da953744b68b9.

Added: 


Modified: 
lldb/include/lldb/Core/ValueObject.h
lldb/include/lldb/Core/ValueObjectCast.h
lldb/include/lldb/Core/ValueObjectChild.h
lldb/include/lldb/Core/ValueObjectConstResult.h
lldb/include/lldb/Core/ValueObjectDynamicValue.h
lldb/include/lldb/Core/ValueObjectMemory.h
lldb/include/lldb/Core/ValueObjectRegister.h
lldb/include/lldb/Core/ValueObjectSyntheticFilter.h
lldb/include/lldb/Core/ValueObjectVTable.h
lldb/include/lldb/Core/ValueObjectVariable.h
lldb/include/lldb/DataFormatters/TypeSynthetic.h
lldb/include/lldb/DataFormatters/VectorIterator.h
lldb/include/lldb/Symbol/CompilerType.h
lldb/include/lldb/Symbol/Type.h
lldb/include/lldb/Symbol/TypeSystem.h
lldb/include/lldb/Target/StackFrameRecognizer.h
lldb/include/lldb/Utility/Log.h
lldb/source/API/SBValue.cpp
lldb/source/Core/FormatEntity.cpp
lldb/source/Core/IOHandlerCursesGUI.cpp
lldb/source/Core/ValueObject.cpp
lldb/source/Core/ValueObjectCast.cpp
lldb/source/Core/ValueObjectChild.cpp
lldb/source/Core/ValueObjectConstResult.cpp
lldb/source/Core/ValueObjectDynamicValue.cpp
lldb/source/Core/ValueObjectMemory.cpp
lldb/source/Core/ValueObjectRegister.cpp
lldb/source/Core/ValueObjectSyntheticFilter.cpp
lldb/source/Core/ValueObjectVTable.cpp
lldb/source/Core/ValueObjectVariable.cpp
lldb/source/DataFormatters/FormatManager.cpp
lldb/source/DataFormatters/TypeSynthetic.cpp
lldb/source/DataFormatters/ValueObjectPrinter.cpp
lldb/source/DataFormatters/VectorType.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp

lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
lldb/source/Plugins/Language/CPlusPlus/BlockPointer.cpp
lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
lldb/source/Plugins/Language/CPlusPlus/Coroutines.h
lldb/source/Plugins/Language/CPlusPlus/GenericBitset.cpp
lldb/source/Plugins/Language/CPlusPlus/GenericOptional.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
lldb/source/Plugins/Language/CPlusPlus/LibCxxAtomic.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxInitializerList.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxQueue.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxRangesRefView.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxSpan.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxValarray.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxVector.cpp
lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
lldb/source/Plugins/Language/CPlusPlus/LibStdcppTuple.cpp
lldb/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
lldb/source/Plugins/Language/ObjC/Cocoa.cpp
lldb/source/Plugins/Language/ObjC/NSArray.cpp
lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
lldb/source/Plugins/Language/ObjC/NSError.cpp
lldb/source/Plugins/Language/ObjC/NSException.cpp
lldb/source/Plugins/Language/ObjC/NSIndexPath.cpp
lldb/source/Plugins/Language/ObjC/NSSet.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
lldb/source/Symbol/CompilerType.cpp
lldb/source/Symbol/Type.cpp
lldb/source/Symbol/Variable.cpp
lldb/source/Target/StackFrame.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index e7e35e2b2bffc0..b4d2c8098edc71 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -476,13 +476,7 @@ class ValueObject {
 
   virtual size_t GetIndexOfChildWithName(llvm::StringRef name);
 
-  llvm::Expected GetNumChildren(uint32_t max = UINT32_MAX);
-  /// Like \c GetNumChildren but returns 0 on error.  You probably
-  /// shouldn't be using this function. It exists primarily to ease the
-  /// transition to more pervasive error handling while not all APIs
-  /// have been updated.
-  uint32_t GetNumChild

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-03-25 Thread Florian Mayer via lldb-commits 

fmayer wrote:

I don't have a strong opinion, but fundamentally I would prefer if the source 
control system stored exactly the files I have in my checkout, not mess with 
them in any way. I understand there are practical concerns, but a linter for 
unexpected CRLF would maybe be an option?

https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-03-25 Thread Florian Mayer via lldb-commits 

fmayer wrote:

> That wish is fine until you start working with others.

Do we actually have that little faith in developers that we think they will 
check in a 50k line diff?

https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-03-25 Thread Florian Mayer via lldb-commits 

fmayer wrote:

> . The point of this patch is not to lambast developers or interfere with 
> their local setups; it's to get the line-ending issues out of the way for 
> good so they can focus on what they do best.

Fair enough. I don't think it will fully make them go away for good, as you 
mentioned "[...] except for specific cases like .bat files or tests for parsers 
that need to accept such sequences." Something somewhere is bound to work 
before the transformation, and no longer after. It's possible that that will be 
more rare, though I would say 100 reverts in all of LLVM history isn't really 
that much either, all things considered.

> And, given what I quoted above, it's not about faith - it's about historical 
> evidence that this is a problem.

I am not saying this isn't a problem at all, but how often has anyone done a 
one line change and caused a 50k diff, and submitted it without noticing?

https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)

2024-03-27 Thread Florian Mayer via lldb-commits 




fmayer wrote:

LGTM, verified the two strings are the same

```
>>> r"^(.*) \(in (.*)\) \((.*:\d*)\)$" == "^(.*) \(in (.*)\) \((.*:\d*)\)$"
True
>>> "^( *#([0-9]+) *)(0x[0-9a-f]+) *(?:in *.+)? *\((.*)\+(0x[0-9a-f]+)\)" == 
>>> r"^( *#([0-9]+) *)(0x[0-9a-f]+) *(?:in *.+)? *\((.*)\+(0x[0-9a-f]+)\)"
```

https://github.com/llvm/llvm-project/pull/86806
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [llvm] [lld] [flang] [clang] [lldb] [libc] [libcxxabi] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

2024-01-30 Thread Florian Mayer via lldb-commits 

https://github.com/fmayer approved this pull request.


https://github.com/llvm/llvm-project/pull/79924
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits