date:20210219

[lldb-dev] [Bug 49269] New: Need to add support for DW_TAG base type 'long double'

2021-02-19 Thread via lldb-dev

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

Bug ID: 49269
   Summary: Need to add support for DW_TAG base type 'long double'
   Product: lldb
   Version: 11.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: bartsm...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Hi,

I like the lldb idea and have used it a lot on linux and MacOs, but never got
it running on Windows. But today I tried again in MinGW64.

lldb does not recognise the tty of mingw. The (lldb) command is not printed
before entering a command, but after. I talked with MinGW developers on this
and by setting MSYS=enable_pcon the program worked properly.

Debugging a program the following error occurred while printing a backtrace:

(lldb) bt
error: need to add support for DW_TAG_base_type 'long double' encoded with
DW_ATE = 0x4, bit_size = 128
error: need to add support for DW_TAG_base_type 'long double' encoded with
DW_ATE = 0x4, bit_size = 128
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0.  Program arguments: C:\msys64\mingw64\bin\lldb.exe 3T.exe
1.  HandleCommand(command = "bt")
2.  HandleCommand(command = "thread backtrace")
 #0 0x7ffdb42cc4a0 (C:\msys64\mingw64\bin\libclang-cpp.dll+0x28c4a0)
 #1 0x7ffdb44a294c (C:\msys64\mingw64\bin\libclang-cpp.dll+0x46294c)
 #2 0x7ffdb42603dd (C:\msys64\mingw64\bin\libclang-cpp.dll+0x2203dd)
 #3 0x7ffdb4252950 (C:\msys64\mingw64\bin\libclang-cpp.dll+0x212950)
 #4 0x7ffdd67d25f1 (C:\msys64\mingw64\bin\liblldb.dll+0x7b25f1)
 #5 0x7ffdd6441f6b (C:\msys64\mingw64\bin\liblldb.dll+0x421f6b)
 #6 0x7ffdd6776241 (C:\msys64\mingw64\bin\liblldb.dll+0x756241)
 #7 0x7ffdd67826ea (C:\msys64\mingw64\bin\liblldb.dll+0x7626ea)
 #8 0x7ffdd675b556 (C:\msys64\mingw64\bin\liblldb.dll+0x73b556)
 #9 0x7ffdd675bad5 (C:\msys64\mingw64\bin\liblldb.dll+0x73bad5)
#10 0x7ffdd675be4d (C:\msys64\mingw64\bin\liblldb.dll+0x73be4d)
#11 0x7ffdd675bfb5 (C:\msys64\mingw64\bin\liblldb.dll+0x73bfb5)
#12 0x7ffdd67835b6 (C:\msys64\mingw64\bin\liblldb.dll+0x7635b6)
#13 0x7ffdd6784b2e (C:\msys64\mingw64\bin\liblldb.dll+0x764b2e)
#14 0x7ffdd6785764 (C:\msys64\mingw64\bin\liblldb.dll+0x765764)
#15 0x7ffdd6785ca8 (C:\msys64\mingw64\bin\liblldb.dll+0x765ca8)
#16 0x7ffdd675a629 (C:\msys64\mingw64\bin\liblldb.dll+0x73a629)
#17 0x7ffdd646200b (C:\msys64\mingw64\bin\liblldb.dll+0x44200b)
#18 0x7ffdd646278a (C:\msys64\mingw64\bin\liblldb.dll+0x44278a)
#19 0x7ffdd6783e89 (C:\msys64\mingw64\bin\liblldb.dll+0x763e89)
#20 0x7ffdd6784b2e (C:\msys64\mingw64\bin\liblldb.dll+0x764b2e)
#21 0x7ffdd6785764 (C:\msys64\mingw64\bin\liblldb.dll+0x765764)
#22 0x7ffdd6785ca8 (C:\msys64\mingw64\bin\liblldb.dll+0x765ca8)
#23 0x7ffdd675a629 (C:\msys64\mingw64\bin\liblldb.dll+0x73a629)
#24 0x7ffdd646200b (C:\msys64\mingw64\bin\liblldb.dll+0x44200b)
#25 0x7ffdd646278a (C:\msys64\mingw64\bin\liblldb.dll+0x44278a)
#26 0x7ffdd6783e89 (C:\msys64\mingw64\bin\liblldb.dll+0x763e89)
#27 0x7ffdd6784b2e (C:\msys64\mingw64\bin\liblldb.dll+0x764b2e)
#28 0x7ffdd6785764 (C:\msys64\mingw64\bin\liblldb.dll+0x765764)
#29 0x7ffdd6785ca8 (C:\msys64\mingw64\bin\liblldb.dll+0x765ca8)
#30 0x7ffdd675a629 (C:\msys64\mingw64\bin\liblldb.dll+0x73a629)
#31 0x7ffdd646200b (C:\msys64\mingw64\bin\liblldb.dll+0x44200b)
#32 0x7ffdd646274a (C:\msys64\mingw64\bin\liblldb.dll+0x44274a)
#33 0x7ffdd6784fe3 (C:\msys64\mingw64\bin\liblldb.dll+0x764fe3)
#34 0x7ffdd6785764 (C:\msys64\mingw64\bin\liblldb.dll+0x765764)
#35 0x7ffdd6785ca8 (C:\msys64\mingw64\bin\liblldb.dll+0x765ca8)
#36 0x7ffdd675a629 (C:\msys64\mingw64\bin\liblldb.dll+0x73a629)
#37 0x7ffdd646200b (C:\msys64\mingw64\bin\liblldb.dll+0x44200b)
#38 0x7ffdd646278a (C:\msys64\mingw64\bin\liblldb.dll+0x44278a)
#39 0x7ffdd6783e89 (C:\msys64\mingw64\bin\liblldb.dll+0x763e89)
#40 0x7ffdd6784b2e (C:\msys64\mingw64\bin\liblldb.dll+0x764b2e)
#41 0x7ffdd6785764 (C:\msys64\mingw64\bin\liblldb.dll+0x765764)
#42 0x7ffdd6785ca8 (C:\msys64\mingw64\bin\liblldb.dll+0x765ca8)
#43 0x7ffdd675a629 (C:\msys64\mingw64\bin\liblldb.dll+0x73a629)
#44 0x7ffdd646200b (C:\msys64\mingw64\bin\liblldb.dll+0x44200b)
#45 0x7ffdd646278a (C:\msys64\mingw64\bin\liblldb.dll+0x44278a)
#46 0x7ffdd6776220 (C:\msys64\mingw64\bin\liblldb.dll+0x756220)
#47 0x7ffdd67826ea (C:\msys64\mingw64\bin\liblldb.dll+0x7626ea)
#48 0x7ffdd675b556 (C:\msys64\mingw64\bin\liblldb.dll+0x73b556)
#49 0x7ffdd675bad5 (C:\msys64\mingw64\bin\liblldb.dll+0x73bad5)
#50 0x7ffdd675be4d (C:\msys64\mingw64\bin\liblldb.dll+0x73be4d)
#51 0x7ffdd6756a65 (C:\msys64\mingw64\bin\liblldb.dll+0x736a65)
#52 0x7ffdd6461d72 (C

Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

2021-02-19 Thread Tom Stellard via lldb-dev


On 2/13/21 9:03 AM, Dimitry Andric wrote:

On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev  
wrote:


I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
binaries.


During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, 
which turned out to be caused by recent libc++ changes:

   FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
   cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
/usr/local/bin/cmake -E env 
CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
/usr/local/bin/python3.7 -m unittest discover
   

The '' signifies 8 errors, which become more clear if "unittest 
discover" is run with the -f (fail immediately) and -v (verbose) options:

   $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
/usr/local/bin/cmake -E env 
CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
/usr/local/bin/python3.7 -m unittest discover -f -v
   test_access_specifiers 
(tests.cindex.test_access_specifiers.TestAccessSpecifiers)
   Ensure that C++ access specifiers are available on cursors ... ERROR

   ==
   ERROR: test_access_specifiers 
(tests.cindex.test_access_specifiers.TestAccessSpecifiers)
   Ensure that C++ access specifiers are available on cursors
   --
   Traceback (most recent call last):
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4173, in get_cindex_library
   library = cdll.LoadLibrary(self.get_filename())
 File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in 
LoadLibrary
   return self._dlltype(name)
 File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
   self._handle = _dlopen(self._name, mode)
   OSError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
Undefined symbol "_ZnamSt11align_val_t"

   During handling of the above exception, another exception occurred:

   Traceback (most recent call last):
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py",
 line 29, in test_access_specifiers
   """, lang = 'cpp')
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py",
 line 41, in get_tu
   source)])
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 2812, in from_source
   index = Index.create()
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 2699, in create
   return Index(conf.lib.clang_createIndex(excludeDecls, 0))
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 212, in __get__
   value = self.wrapped(instance)
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4147, in lib
   lib = self.get_cindex_library()
 File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4178, in get_cindex_library
   raise LibclangError(msg)
   clang.cindex.LibclangError: 
/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined 
symbol "_ZnamSt11align_val_t". To provide a path to libclang use 
Config.set_library_path() or Config.set_library_file().

   --
   Ran 1 test in 0.027s

   FAILED (errors=1)

It turns out that libc++.so.1 now depends on the symbol '_ZnamSt11align_val_t', 
which is 'operator new [](unsigned long, std::align_val_t)'. Embarassingly, 
libc++.so.1 has always depended on this C++17 specific variant of operator new. 
But FreeBSD's C++ ABI library, libcxxrt, has never supported this variant!

Previously, this never was a problem, because libc++ provided its own weak definitions of 
these operators. But recently the define _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was 
toggled to on by default, which disables those definitions. This happened in 
9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in libc++abi 
only by default") by Louis Dionne.

While this is reasonable for the libc++abi situation, where it might lead to 
circular dependencies, I would like to turn the definitions on again in case 
libcxxrt is used for the C++ ABI, such as on FreeBSD.

If you think this is a reasonable approach, I will create a review for it. 
Otherwise, I will have to patch the test-release.sh script to pass 
-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.



I'm not sure what the best solution is.  Can you file a bug for this and CC 
Louis.

-Tom


-Dimitry



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

Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

2021-02-19 Thread Tom Stellard via lldb-dev


On 2/13/21 1:44 PM, Louis Dionne wrote:




On Feb 13, 2021, at 12:04, Dimitry Andric  wrote:

On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev  
wrote:


I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
binaries.


During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, 
which turned out to be caused by recent libc++ changes:

  FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
  cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
/usr/local/bin/cmake -E env 
CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
/usr/local/bin/python3.7 -m unittest discover
  

The '' signifies 8 errors, which become more clear if "unittest 
discover" is run with the -f (fail immediately) and -v (verbose) options:

  $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
/usr/local/bin/cmake -E env 
CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
/usr/local/bin/python3.7 -m unittest discover -f -v
  test_access_specifiers 
(tests.cindex.test_access_specifiers.TestAccessSpecifiers)
  Ensure that C++ access specifiers are available on cursors ... ERROR

  ==
  ERROR: test_access_specifiers 
(tests.cindex.test_access_specifiers.TestAccessSpecifiers)
  Ensure that C++ access specifiers are available on cursors
  --
  Traceback (most recent call last):
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4173, in get_cindex_library
  library = cdll.LoadLibrary(self.get_filename())
File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
  return self._dlltype(name)
File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
  self._handle = _dlopen(self._name, mode)
  OSError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
Undefined symbol "_ZnamSt11align_val_t"

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py",
 line 29, in test_access_specifiers
  """, lang = 'cpp')
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py",
 line 41, in get_tu
  source)])
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 2812, in from_source
  index = Index.create()
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 2699, in create
  return Index(conf.lib.clang_createIndex(excludeDecls, 0))
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 212, in __get__
  value = self.wrapped(instance)
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4147, in lib
  lib = self.get_cindex_library()
File 
"/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
line 4178, in get_cindex_library
  raise LibclangError(msg)
  clang.cindex.LibclangError: 
/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined 
symbol "_ZnamSt11align_val_t". To provide a path to libclang use 
Config.set_library_path() or Config.set_library_file().

  --
  Ran 1 test in 0.027s

  FAILED (errors=1)

It turns out that libc++.so.1 now depends on the symbol '_ZnamSt11align_val_t', 
which is 'operator new [](unsigned long, std::align_val_t)'. Embarassingly, 
libc++.so.1 has always depended on this C++17 specific variant of operator new. 
But FreeBSD's C++ ABI library, libcxxrt, has never supported this variant!

Previously, this never was a problem, because libc++ provided its own weak definitions of 
these operators. But recently the define _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was 
toggled to on by default, which disables those definitions. This happened in 
9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in libc++abi 
only by default") by Louis Dionne.

While this is reasonable for the libc++abi situation, where it might lead to 
circular dependencies, I would like to turn the definitions on again in case 
libcxxrt is used for the C++ ABI, such as on FreeBSD.

If you think this is a reasonable approach, I will create a review for it. 
Otherwise, I will have to patch the test-release.sh script to pass 
-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.


The correct approach would be to have a CMake cache file under 
libcxx/cmake/cache/FreeBSD.cmake that sets the right configuration for building 
libcxx as a system library on freebsd. That way, the cmake code itself can stay 
free of platform specific logic.

Also

Re: [lldb-dev] [cfe-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

2021-02-19 Thread Tom Stellard via lldb-dev


On 2/19/21 7:07 AM, Yvan Roux wrote:

Hi,

I've built, tested and uploaded ARM and AArch64 binaries:

22bff83933ef52e605f89193165faaa6  clang+llvm-12.0.0-rc1-aarch64-linux-gnu.tar.xz
feb0f3d832a6a8a1265db0533cd9fc77  
clang+llvm-12.0.0-rc1-armv7a-linux-gnueabihf.tar.xz



Which hash algorithm did you use?  Also can you post the file sizes?

-Tom



A few errors observed with ARMv7 LLD:

  cfi-devirt-lld-armhf :: cross-dso/simple-fail.cpp
   cfi-devirt-lld-armhf :: cross-dso/simple-pass.cpp
   cfi-devirt-lld-armhf :: cross-dso/stats.cpp
   cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
   cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
   cfi-devirt-lld-thinlto-armhf :: cross-dso/stats.cpp
   cfi-standalone-lld-armhf :: cross-dso/simple-fail.cpp
   cfi-standalone-lld-armhf :: cross-dso/simple-pass.cpp
   cfi-standalone-lld-armhf :: cross-dso/stats.cpp
   cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
   cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
   cfi-standalone-lld-thinlto-armhf :: cross-dso/stats.cpp

Cheers,
Yvan


On Sun, 14 Feb 2021 at 23:24, Dimitry Andric via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote:

On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote:
 >
 > I've tagged the 12.0.0-rc1 release.  Testers can begin testing and 
upload binaries.

For 12.0.0 rc1, I have built and tested on both FreeBSD 11 and 12. I
used two patches, which are attached.


Main results on amd64-freebsd11:

   Unsupported        :  5557
   Passed             : 80122
   Expectedly Failed  :   246
   Timed Out          :     2
   Failed             :    95
   Unexpectedly Passed:     2

Test suite results on amd64-freebsd11:

   Passed: 2399
   Failed:    3


Main results on amd64-freebsd12:

   Unsupported        :  5557
   Passed             : 80125
   Expectedly Failed  :   242
   Timed Out          :     4
   Failed             :    90
   Unexpectedly Passed:     6

Test suite results on amd64-freebsd12:

   Passed: 2399
   Failed:    3


Main results on i386-freebsd11:

   Unsupported        :  3971
   Passed             : 76669
   Expectedly Failed  :   223
   Failed             :    51
   Unexpectedly Passed:     1


Main results on i386-freebsd12:

   Unsupported        :  3971
   Passed             : 76672
   Expectedly Failed  :   221
   Failed             :    48
   Unexpectedly Passed:     3


Uploaded:
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 
435e727287b9a3bf3f2da9bfec9d37b1118a59774885f0dd3597018f89515a4f
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = 
b2e49f56880fefe4bff2c45e74bfb55b2186fc16757a1b5d1b19f17dff9f49dd
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 
10f0e81e4d516b46aff8dc22af1cc6eb9db0ec9c3a43b6941b51a6728255d311
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd12.tar.xz) = 
077719695ebe6be1f55fb82eae483a9c550512809c6b272abfef9b2f84ada58e

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




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

Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

2021-02-19 Thread Dimitry Andric via lldb-dev

On 19 Feb 2021, at 19:14, Tom Stellard  wrote:
> 
> On 2/13/21 1:44 PM, Louis Dionne wrote:
>>> On Feb 13, 2021, at 12:04, Dimitry Andric  wrote:
>>> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev 
>>>  wrote:
 
 I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
 binaries.
>>> 
>>> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest 
>>> failure, which turned out to be caused by recent libc++ changes:
...
>>> If you think this is a reasonable approach, I will create a review for it. 
>>> Otherwise, I will have to patch the test-release.sh script to pass 
>>> -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on 
>>> FreeBSD.
>> The correct approach would be to have a CMake cache file under 
>> libcxx/cmake/cache/FreeBSD.cmake that sets the right configuration for 
>> building libcxx as a system library on freebsd. That way, the cmake code 
>> itself can stay free of platform specific logic.
>> Also note that I remember asking vendors before making that change, but I 
>> guess I either forgot to ask Freebsd or you told me OK without thinking 
>> about this. I can’t verify which one happened because I’m on my phone, but 
>> I’ll check it out to make sure I have your contact information if I need to 
>> ask that sort of questions in the future. It could be useful to have some 
>> sort of libcxx-vendors group in Phabricator that I could tag whenever I want 
>> to ping you folks.
>> Please send a Phab and I’ll revise it quickly (probably on Monday morning).
> 
> Has this been fixed in the branch yet?

Yes, I submitted https://bugs.llvm.org/show_bug.cgi?id=49197, and you merged 
the fix in d14016d869ac. Thanks! :)

(That said, more work should probably be done on this particular issue, but the 
merged fix is good enough for the release.)

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 49269] New: Need to add support for DW_TAG base type 'long double'

Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

Re: [lldb-dev] [cfe-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged

5 matches

Site Navigation

Mail list logo

Footer information