Re: [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

[Jim Ingham via lldb-dev]

Yeah, I take that part back.  It sort of makes sense that you build the server 
for the architecture you are building binaries for, since the server has to run 
wherever the binaries run.  If we were being strict about that, we'd build one 
server for each backend we build clang for, but we don't do that.  So maybe 
this is the best guess for what the builder intended.  This was a side comment, 
and not the main question.

Jim


> On Oct 30, 2019, at 11:55 AM, Ted Woodward  wrote:
> 
> I'm not going to comment on the change (my cmake knowledge is a hair more 
> than yours, but not enough for this), but LLVM_DEFAULT_TARGET_TRIPLE is the 
> default backend. LLVM_HOST_TRIPLE is the triple we're running on. In your 
> example, LLVM_DEFAULT_TARGET_TRIPLE should be something like arm-apple-darwin 
> and LLVM_HOST_TRIPLE should be something like x86_64-apple-darwin. I'm not 
> sure what the exact triples are :-)
> 
> When we build Hexagon tools, LLVM_DEFAULT_TARGET_TRIPLE, LLVM_TARGET_ARCH and 
> TARGET_TRIPLE are hexagon-unknown--elf. LLVM_HOST_TRIPLE is either 
> x86_64-unknown-linux or x86_64-pc-windows.
> 
>> -Original Message-
>> From: lldb-dev  On Behalf Of Jim Ingham via
>> lldb-dev
>> Sent: Wednesday, October 30, 2019 1:37 PM
>> To: LLDB 
>> Subject: [EXT] [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to
>> lldb's cmakery
>> 
>> Hi, all...
>> 
>> Saleem submitted a patch to work around some other changes in llvm
>> cmakery that was making LLVM_DEFAULT_TARGET_TRIPLE undefined when
>> lldb went to use it for the macOS debugserver build.
>> 
>> That was:
>> 
>> commit 55eec2ba96bd9c19ccb5d4d13cb8c88d4abcebc6
>> Author: Saleem Abdulrasool 
>> Date:   Tue Oct 29 08:20:58 2019 -0700
>> 
>>build: workaround stale caches (NFC)
>> 
>>`LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it
>>may actually be unset.  Furthermore, in standalone builds, the variable
>>may be fully undefined.  Apply the regular expression over the empty
>>string in such a case.  This should improve the state of the green
>>dragon bot.
>> 
>> But that change:
>> 
>> -string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
>> ${LLVM_DEFAULT_TARGET_TRIPLE})
>> +string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
>> +"${LLVM_DEFAULT_TARGET_TRIPLE}")
>> 
>> didn't work.  If LLVM_DEFAULT_TARGET_TRIPLE is not set, then CMake fails
>> with:
>> 
>> CMake Error at tools/debugserver/source/MacOSX/CMakeLists.txt:13 (string):
>>  string sub-command REGEX, mode MATCH regex "^[^-]*" matched an empty
>>  string.
>> 
>> and the generation stops.
>> 
>> It seems weird to me that successfully matching against an empty string is an
>> error, I'd think you would copy an empty string to the target variable.  But 
>> my
>> knowledge of CMake pretty much stops at "the C and the M are capitalized,
>> the rest aren't..."
>> 
>> Anyway, another way to do this would be something like:
>> 
>> #if (${LLVM_DEFAULT_TARGET_TRIPLE})
>>  string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
>> "${LLVM_DEFAULT_TARGET_TRIPLE}")
>> #else()
>> #  set(LLDB_DEBUGSERVER_ARCH "")
>> #endif()
>> 
>> Which would then dial up the default architecture (x86_64) further on.  But
>> Vedant thought instead of this, it would be more generally useful to assure
>> that LLVM_DEFAULT_TARGET_TRIPLE was exported, like:
>> 
>> diff --git i/llvm/cmake/modules/LLVMConfig.cmake.in
>> w/llvm/cmake/modules/LLVMConfig.cmake.in
>> index 7fdca536c1f..e875e661a02 100644
>> --- i/llvm/cmake/modules/LLVMConfig.cmake.in
>> +++ w/llvm/cmake/modules/LLVMConfig.cmake.in
>> @@ -92,6 +92,7 @@ set(LLVM_TOOLS_INSTALL_DIR
>> "@LLVM_TOOLS_INSTALL_DIR@")  set(LLVM_HAVE_OPT_VIEWER_MODULES
>> @LLVM_HAVE_OPT_VIEWER_MODULES@)
>> set(LLVM_CONFIGURATION_TYPES @CMAKE_CONFIGURATION_TYPES@)
>> set(LLVM_ENABLE_SHARED_LIBS @BUILD_SHARED_LIBS@)
>> +set(LLVM_DEFAULT_TARGET_TRIPLE "@LLVM_DEFAULT_TARGET_TRIPLE@")
>> 
>> if(NOT TARGET LLVMSupport)
>>   set(LLVM_EXPORTED_TARGETS "@LLVM_CONFIG_EXPORTS@")
>> 
>> I'm a little hesitant to propose this change as I don't have a good sense of 
>> the
>> ramifications of doing this, or why it wasn't done this way to begin with.
>> 
>> LLVM_DEFAULT_TARGET_TRIPLE seems like an oddly named variable to use
>> for the host OS that we're building for.  If I build an x86_64-darwin hosted
>> compiler but only included the arm backend, it would be odd to have the
>> default target triple be x86_64-darwin, so I'm surely missing something...
>> 
>> Anyway, so I wanted first to float the question here before suggesting a
>> change.
>> 
>> Jim
>> 
>> ___
>> 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

Re: [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

[Ted Woodward via lldb-dev]

I'm not going to comment on the change (my cmake knowledge is a hair more than 
yours, but not enough for this), but LLVM_DEFAULT_TARGET_TRIPLE is the default 
backend. LLVM_HOST_TRIPLE is the triple we're running on. In your example, 
LLVM_DEFAULT_TARGET_TRIPLE should be something like arm-apple-darwin and 
LLVM_HOST_TRIPLE should be something like x86_64-apple-darwin. I'm not sure 
what the exact triples are :-)

When we build Hexagon tools, LLVM_DEFAULT_TARGET_TRIPLE, LLVM_TARGET_ARCH and 
TARGET_TRIPLE are hexagon-unknown--elf. LLVM_HOST_TRIPLE is either 
x86_64-unknown-linux or x86_64-pc-windows.

> -Original Message-
> From: lldb-dev  On Behalf Of Jim Ingham via
> lldb-dev
> Sent: Wednesday, October 30, 2019 1:37 PM
> To: LLDB 
> Subject: [EXT] [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to
> lldb's cmakery
>
> Hi, all...
>
> Saleem submitted a patch to work around some other changes in llvm
> cmakery that was making LLVM_DEFAULT_TARGET_TRIPLE undefined when
> lldb went to use it for the macOS debugserver build.
>
> That was:
>
> commit 55eec2ba96bd9c19ccb5d4d13cb8c88d4abcebc6
> Author: Saleem Abdulrasool 
> Date:   Tue Oct 29 08:20:58 2019 -0700
>
> build: workaround stale caches (NFC)
>
> `LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it
> may actually be unset.  Furthermore, in standalone builds, the variable
> may be fully undefined.  Apply the regular expression over the empty
> string in such a case.  This should improve the state of the green
> dragon bot.
>
> But that change:
>
> -string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> ${LLVM_DEFAULT_TARGET_TRIPLE})
> +string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> +"${LLVM_DEFAULT_TARGET_TRIPLE}")
>
> didn't work.  If LLVM_DEFAULT_TARGET_TRIPLE is not set, then CMake fails
> with:
>
> CMake Error at tools/debugserver/source/MacOSX/CMakeLists.txt:13 (string):
>   string sub-command REGEX, mode MATCH regex "^[^-]*" matched an empty
>   string.
>
> and the generation stops.
>
> It seems weird to me that successfully matching against an empty string is an
> error, I'd think you would copy an empty string to the target variable.  But 
> my
> knowledge of CMake pretty much stops at "the C and the M are capitalized,
> the rest aren't..."
>
> Anyway, another way to do this would be something like:
>
> #if (${LLVM_DEFAULT_TARGET_TRIPLE})
>   string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> "${LLVM_DEFAULT_TARGET_TRIPLE}")
> #else()
> #  set(LLDB_DEBUGSERVER_ARCH "")
> #endif()
>
> Which would then dial up the default architecture (x86_64) further on.  But
> Vedant thought instead of this, it would be more generally useful to assure
> that LLVM_DEFAULT_TARGET_TRIPLE was exported, like:
>
> diff --git i/llvm/cmake/modules/LLVMConfig.cmake.in
> w/llvm/cmake/modules/LLVMConfig.cmake.in
> index 7fdca536c1f..e875e661a02 100644
> --- i/llvm/cmake/modules/LLVMConfig.cmake.in
> +++ w/llvm/cmake/modules/LLVMConfig.cmake.in
> @@ -92,6 +92,7 @@ set(LLVM_TOOLS_INSTALL_DIR
> "@LLVM_TOOLS_INSTALL_DIR@")  set(LLVM_HAVE_OPT_VIEWER_MODULES
> @LLVM_HAVE_OPT_VIEWER_MODULES@)
> set(LLVM_CONFIGURATION_TYPES @CMAKE_CONFIGURATION_TYPES@)
> set(LLVM_ENABLE_SHARED_LIBS @BUILD_SHARED_LIBS@)
> +set(LLVM_DEFAULT_TARGET_TRIPLE "@LLVM_DEFAULT_TARGET_TRIPLE@")
>
>  if(NOT TARGET LLVMSupport)
>set(LLVM_EXPORTED_TARGETS "@LLVM_CONFIG_EXPORTS@")
>
> I'm a little hesitant to propose this change as I don't have a good sense of 
> the
> ramifications of doing this, or why it wasn't done this way to begin with.
>
> LLVM_DEFAULT_TARGET_TRIPLE seems like an oddly named variable to use
> for the host OS that we're building for.  If I build an x86_64-darwin hosted
> compiler but only included the arm backend, it would be odd to have the
> default target triple be x86_64-darwin, so I'm surely missing something...
>
> Anyway, so I wanted first to float the question here before suggesting a
> change.
>
> Jim
>
> ___
> 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

Re: [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

[Davide Italiano via lldb-dev]

On Wed, Oct 30, 2019 at 11:52 AM Jim Ingham via lldb-dev
 wrote:
>
> Except of course without the comment markers...
>
> > On Oct 30, 2019, at 11:36 AM, Jim Ingham  wrote:
> >
> > Anyway, another way to do this would be something like:
> >
> > #if (${LLVM_DEFAULT_TARGET_TRIPLE})
> >  string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH 
> > "${LLVM_DEFAULT_TARGET_TRIPLE}")
> > #else()
> > #  set(LLDB_DEBUGSERVER_ARCH "")
> > #endif()
> >
>
> ___
> 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

Re: [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

[Jim Ingham via lldb-dev]

Except of course without the comment markers...

> On Oct 30, 2019, at 11:36 AM, Jim Ingham  wrote:
> 
> Anyway, another way to do this would be something like:
> 
> #if (${LLVM_DEFAULT_TARGET_TRIPLE})
>  string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH 
> "${LLVM_DEFAULT_TARGET_TRIPLE}")
> #else()
> #  set(LLDB_DEBUGSERVER_ARCH "")  
> #endif()
> 

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

[lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

[Jim Ingham via lldb-dev]

Hi, all...

Saleem submitted a patch to work around some other changes in llvm cmakery that 
was making LLVM_DEFAULT_TARGET_TRIPLE undefined when lldb went to use it for 
the macOS debugserver build.

That was:

commit 55eec2ba96bd9c19ccb5d4d13cb8c88d4abcebc6
Author: Saleem Abdulrasool 
Date:   Tue Oct 29 08:20:58 2019 -0700

build: workaround stale caches (NFC)

`LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it
may actually be unset.  Furthermore, in standalone builds, the variable
may be fully undefined.  Apply the regular expression over the empty
string in such a case.  This should improve the state of the green
dragon bot.

But that change:

-string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH 
${LLVM_DEFAULT_TARGET_TRIPLE})
+string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH 
"${LLVM_DEFAULT_TARGET_TRIPLE}")
 
didn't work.  If LLVM_DEFAULT_TARGET_TRIPLE is not set, then CMake fails with:

CMake Error at tools/debugserver/source/MacOSX/CMakeLists.txt:13 (string):
  string sub-command REGEX, mode MATCH regex "^[^-]*" matched an empty
  string.

and the generation stops.

It seems weird to me that successfully matching against an empty string is an 
error, I'd think you would copy an empty string to the target variable.  But my 
knowledge of CMake pretty much stops at "the C and the M are capitalized, the 
rest aren't..."

Anyway, another way to do this would be something like:

#if (${LLVM_DEFAULT_TARGET_TRIPLE})
  string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH 
"${LLVM_DEFAULT_TARGET_TRIPLE}")
#else()
#  set(LLDB_DEBUGSERVER_ARCH "")  
#endif()

Which would then dial up the default architecture (x86_64) further on.  But 
Vedant thought instead of this, it would be more generally useful to assure 
that LLVM_DEFAULT_TARGET_TRIPLE was exported, like:

diff --git i/llvm/cmake/modules/LLVMConfig.cmake.in 
w/llvm/cmake/modules/LLVMConfig.cmake.in
index 7fdca536c1f..e875e661a02 100644
--- i/llvm/cmake/modules/LLVMConfig.cmake.in
+++ w/llvm/cmake/modules/LLVMConfig.cmake.in
@@ -92,6 +92,7 @@ set(LLVM_TOOLS_INSTALL_DIR "@LLVM_TOOLS_INSTALL_DIR@")
 set(LLVM_HAVE_OPT_VIEWER_MODULES @LLVM_HAVE_OPT_VIEWER_MODULES@)
 set(LLVM_CONFIGURATION_TYPES @CMAKE_CONFIGURATION_TYPES@)
 set(LLVM_ENABLE_SHARED_LIBS @BUILD_SHARED_LIBS@)
+set(LLVM_DEFAULT_TARGET_TRIPLE "@LLVM_DEFAULT_TARGET_TRIPLE@")
 
 if(NOT TARGET LLVMSupport)
   set(LLVM_EXPORTED_TARGETS "@LLVM_CONFIG_EXPORTS@")

I'm a little hesitant to propose this change as I don't have a good sense of 
the ramifications of doing this, or why it wasn't done this way to begin with.  

LLVM_DEFAULT_TARGET_TRIPLE seems like an oddly named variable to use for the 
host OS that we're building for.  If I build an x86_64-darwin hosted compiler 
but only included the arm backend, it would be odd to have the default target 
triple be x86_64-darwin, so I'm surely missing something...

Anyway, so I wanted first to float the question here before suggesting a change.

Jim

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

[lldb-dev] [Bug 43852] New: FTBFS: file INSTALL cannot find "/builddir/build/BUILD/lldb-9.0.0.src/clr-build/./lib64/python3.7".

[via lldb-dev]

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

Bug ID: 43852
   Summary: FTBFS: file INSTALL cannot find
"/builddir/build/BUILD/lldb-9.0.0.src/clr-build/./lib6
4/python3.7".
   Product: lldb
   Version: 9.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: thi...@kde.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

(Failure to build from source)

When building lldb 9.0.0 on Clear Linux, with Python 3.7, lldb fails to build.

Configured as:
cmake -G 'Unix Makefiles' -DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_SBINDIR=/usr/bin
-DCMAKE_INSTALL_LIBDIR=/usr/lib64 -DLIB_INSTALL_DIR=/usr/lib64 -DLIB_SUFFIX=64
-DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_RANLIB=/usr/bin/gcc-ranlib ..  -DLLVM_HOST_TRIPLE=x86_64-generic-linux
-DLLVM_LIBDIR_SUFFIX=64 -DLLVM_LINK_LLVM_DYLIB:BOOL=ON
-DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3

Build succeeds, but fails to install:

-- Installing:
/builddir/build/BUILDROOT/lldb-9.0.0-2.x86_64/usr/include/lldb/Host/ProcessLauncher.h
-- Up-to-date: /builddir/build/BUILDROOT/lldb-9.0.0-2.x86_64/usr/include
-- Up-to-date: /builddir/build/BUILDROOT/lldb-9.0.0-2.x86_64/usr/include/lldb
-- Up-to-date:
/builddir/build/BUILDROOT/lldb-9.0.0-2.x86_64/usr/include/lldb/Host
-- Installing:
/builddir/build/BUILDROOT/lldb-9.0.0-2.x86_64/usr/include/lldb/Host/Config.h
CMake Error at scripts/cmake_install.cmake:41 (file):
  file INSTALL cannot find
  "/builddir/build/BUILD/lldb-9.0.0.src/clr-build/./lib64/python3.7".
Call Stack (most recent call first):
  cmake_install.cmake:50 (include)


make: *** [Makefile:74: install] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.GgR7lj (%install)

Python info:

$ python -c 'import sys; print(sys.implementation); print(sys.path)' 
namespace(_multiarch='x86_64-linux-gnu', cache_tag='cpython-37',
hexversion=50791920, name='cpython', version=sys.version_info(major=3, minor=7,
micro=5, releaselevel='final', serial=0))
['', '/usr/lib/python37.zip', '/usr/lib/python3.7',
'/usr/lib/python3.7/lib-dynload', '/usr/lib/python3.7/site-packages']

Full build log attached.

-- 
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] RFC: DWZ = DW_TAG_imported_unit + separate DWARF common file

[Jan Kratochvil via lldb-dev]

Hi,

I would like to get a design approval before I do all remaining technical
cleanups of (3) below.

It was discussed before at:
[lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary 
files
https://lists.llvm.org/pipermail/lldb-dev/2017-August/012656.html
Message-ID: <20170823210611.ga8...@host1.jankratochvil.net>

DWZ principle: DW_TAG_compile_unit can use DW_TAG_imported_unit to "include"
some other DW_TAG_partial_unit. This can happen transitively==recursively.
Unfortunately DW_TAG_partial_unit does not contain DW_AT_language so for
GetLanguageType() LLDB needs to read DW_TAG_compile_unit which included it
and read its DW_AT_language there. Two DW_TAG_compile_unit's with different
DW_AT_language can include (=DW_TAG_imported_unit) the same DW_TAG_partial_unit.

(1) Originally I tried to create 1:1 DWARFCompileUnit mapping to
DW_TAG_partial_unit. This did not work as each DWARFCompileUnit gets
mapped to CompileUnit and multiple CompileUnit's in the same block lead to:
Assertion `!Parent || >getParentASTContext() == ' failed.

(2) Then I tried creating N:1 DWARFCompileUnit's for each DW_TAG_partial_unit,
that is a 1:1 DWARFCompileUnit for each DW_TAG_imported_unit "inclusion".
That worked perfectly but it was considered needlessly ineffective:
  [Lldb-commits] [PATCH] D45170: Cleanup DWARFCompileUnit and DWARFUnit in 
preparation for adding DWARFTypeUnit
  
https://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180409/040211.html
It was mapping each DW_TAG_partial_unit from its DWARFFileOffset to
a new virtual dw_offset_t by MainCU_FileOffsetToCU():
https://reviews.llvm.org/D40474?id=138860
It needed to remap dw_offset_t back to DWARFFileOffset to read
DWARFUnit::m_die_array without a data copy for each DW_TAG_imported_unit.

(3)
My current patch proposal is to create 1:1 DWARFPartialUnit (*1) mapping to
DW_TAG_partial_unit. To support GetLanguageType() for DWARFPartialUnit one
must track the original DWARFCompileUnit * (DW_TAG_compile_unit) in any
DIERef or DWARFBaseDIE. DWARFPartialUnit itself can be used by multiple
DWARFCompileUnit's. I have replaced 'DWARFUnit *' at many places by:
class DWARFUnitPair { DWARFUnit *m_cu; DWARFCompileUnit *m_main_cu; };

(*1) There is no DWARFPartialUnit, DW_TAG_partial_unit is represented by
DWARFCompileUnit. During scanning of CUs it is too expensive to read the
first DIE whether it is DW_TAG_compile_unit or DW_TAG_partial_unit.
DWARFPartialUnit would make sense with DWARF-5 DWZ DW_UT_partial but the
current only existing DWZ tool does not support DWARF-5 yet.

Therefore any AST contexts are made only for DW_TAG_compile_unit,
DW_TAG_partial_unit never has its own AST context. Also any
DW_TAG_partial_unit DIEs are duplicated as AST for each use of
DW_TAG_imported_unit. I hope I did not miss some such more optimal possibility
but I prefer to decompress DWZ on DWARF level than on AST level as the DWZ
tool also does not interpret much the DWARF data when finding common DWARF
DIEs.

Stays the same for as once instance for DW_TAG_partial_unit:
  DWARFDebugInfoEntry: no DWARFUnit reference, kept intact
sizeof(): stays 16
Gets duplicated for each DW_TAG_imported_unit:
  DWARFBaseDIE: DWARFUnit *m_cu, DWARFDebugInfoEntry *m_die,
now added also: DWARFCompileUnit *m_main_cu (in DWARFUnitPair)
sizeof(): 16 -> 24 (new DWARFCompileUnit *m_main_cu)
Only DWARFTypeUnit DIEs must have DWARFCompileUnit *m_main_cu as nullptr,
  they contain DW_AT_language so m_main_cu is not really needed for them.
  DIERef sizeof(): stays 8 (it now remembers parent DWARFCompileUnit's index)
Only for temporary variables:
  new DWARFSimpleDIE: DWARFUnit *m_cu, DWARFDebugInfoEntry *m_die
   - it is like original DWARFBaseDIE for a few cases (like Reference())
 where I need DWARFUnit *m_cu but DWARFCompileUnit *m_main_cu is not known.
   - DWARFSimpleDIE is now standalone, maybe DWARFBaseDIE could inherit it?

Some functions needing parent DWARFCompileUnit *m_main_cu were moved from
DWARFUnit to DWARFCompileUnit: LookupAddress, AppendDIEsWithTag,
GetTypeSystem, GetLanguageType, GetUnitDIEOnly, DIE, GetDIE,

  git remote add jankratochvil git://git.jankratochvil.net/lldb
  git fetch jankratochvil
  git checkout jankratochvil/dwz
or:
  git clone -b dwz git://git.jankratochvil.net/lldb
Full patch:
  https://people.redhat.com/jkratoch/dwz-2019-10-30.patch
Patch part showing the usage of DWARFUnitPair:
  https://people.redhat.com/jkratoch/dwz-DWARFUnitPair-2019-10-30.patch


Thanks,
Jan

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

Re: [lldb-dev] issue with lldb9 and python3.5

[Pavel Labath via lldb-dev]

On 30/10/2019 11:18, Kamil Rytarowski wrote:

On 30.10.2019 11:06, Pavel Labath wrote:

On 29/10/2019 21:40, Christos Zoulas wrote:

On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
-- Subject: Re: [lldb-dev] issue with lldb9 and python3.5

| On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
| > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
| >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
| >
| > I investigated the bug yesterday, and filled some of my
discoveries in
| >
| >  https://bugs.llvm.org/show_bug.cgi?id=43830
| >
| > TLDR: libpython uses libreadline and lldb uses libedit, and that's
a mess.
|
| Hey Christos,
|
| could I bother you to take a look at this python PR
| , and the related lldb
bug
| ?
|
| The executive summary is that there is an incompatibility between
| readline and its libedit emulation, which python needs to work around.
| Is there any way this can be fixed in libedit?
|
| I guess the presence of the workaround will make the fix tricky,
because
| then the workaround will be wrong for the "fixed" libedit, but it's
| still probably worth it to try to resolve this somehow.
|
| WDYT?

I don't know what I have to do here. Can someone explain to me what the
issue is?


I haven't dug into this (maybe Serge can explain in more detail), but I
think this comment (Modules/readline.c in python sources) gives a
general overview of the problem. Ignore the "On OSX" part, the same
should apply to any OS.

/*
  * It is possible to link the readline module to the readline
  * emulation library of editline/libedit.
  *
  * On OSX this emulation library is not 100% API compatible
  * with the "real" readline and cannot be detected at compile-time,
  * hence we use a runtime check to detect if we're using libedit
  *
  * Currently there is one known API incompatibility:
  * - 'get_history' has a 1-based index with GNU readline, and a 0-based
  *   index with older versions of libedit's emulation.
  * - Note that replace_history and remove_history use a 0-based index
  *   with both implementations.
  */

Furthermore, you can probably look at every instance of
if(using_libedit_emulation) in that file (or via this link
),
as each one indicates a workaround for some libedit incompatibility. It
looks like not all of them are still relevant, as it seems some of them
are there just for the sake of old libedit bugs which have since been
fixed, but it looks like at least some of them are. Serge, can you tell
what exactly was the problem which caused the crash?

pl


Is this a packaging issue?

There are good reasons to use libedit as a gnu readline drop in
replacement. The most important one is certainly saner licensing state
as gnu readline is GPLv3 and it makes it incompatible with at least
GPLv2 users (there are users that pick old gnureadline GPLv2 around).

If there are known incompatibilities, I think (not speaking on behalf of
Christos) it would be best to contribute patches with rationale. Generic
call for compatibility might not work well.




Well, I was hoping that for someone intimately familiar with libedit 
(i.e., Christos) the difference in behavior would be obvious from just 
looking at that patch. :) But, of course, I can't make anyone do 
anything (nor I want to do that), so if fixing/figuring that out 
requires more time than you're willing to devote to that right now, then 
yes, I guess it means I or someone else will have to dive in and figure 
out what's wrong (eventually).


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

Re: [lldb-dev] issue with lldb9 and python3.5

[Kamil Rytarowski via lldb-dev]

On 30.10.2019 11:06, Pavel Labath wrote:
> On 29/10/2019 21:40, Christos Zoulas wrote:
>> On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
>> -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5
>>
>> | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
>> | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
>> | >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
>> | >
>> | > I investigated the bug yesterday, and filled some of my
>> discoveries in
>> | >
>> | >  https://bugs.llvm.org/show_bug.cgi?id=43830
>> | >
>> | > TLDR: libpython uses libreadline and lldb uses libedit, and that's
>> a mess.
>> |
>> | Hey Christos,
>> |
>> | could I bother you to take a look at this python PR
>> | , and the related lldb
>> bug
>> | ?
>> |
>> | The executive summary is that there is an incompatibility between
>> | readline and its libedit emulation, which python needs to work around.
>> | Is there any way this can be fixed in libedit?
>> |
>> | I guess the presence of the workaround will make the fix tricky,
>> because
>> | then the workaround will be wrong for the "fixed" libedit, but it's
>> | still probably worth it to try to resolve this somehow.
>> |
>> | WDYT?
>>
>> I don't know what I have to do here. Can someone explain to me what the
>> issue is?
> 
> I haven't dug into this (maybe Serge can explain in more detail), but I
> think this comment (Modules/readline.c in python sources) gives a
> general overview of the problem. Ignore the "On OSX" part, the same
> should apply to any OS.
> 
> /*
>  * It is possible to link the readline module to the readline
>  * emulation library of editline/libedit.
>  *
>  * On OSX this emulation library is not 100% API compatible
>  * with the "real" readline and cannot be detected at compile-time,
>  * hence we use a runtime check to detect if we're using libedit
>  *
>  * Currently there is one known API incompatibility:
>  * - 'get_history' has a 1-based index with GNU readline, and a 0-based
>  *   index with older versions of libedit's emulation.
>  * - Note that replace_history and remove_history use a 0-based index
>  *   with both implementations.
>  */
> 
> Furthermore, you can probably look at every instance of
> if(using_libedit_emulation) in that file (or via this link
> ),
> as each one indicates a workaround for some libedit incompatibility. It
> looks like not all of them are still relevant, as it seems some of them
> are there just for the sake of old libedit bugs which have since been
> fixed, but it looks like at least some of them are. Serge, can you tell
> what exactly was the problem which caused the crash?
> 
> pl

Is this a packaging issue?

There are good reasons to use libedit as a gnu readline drop in
replacement. The most important one is certainly saner licensing state
as gnu readline is GPLv3 and it makes it incompatible with at least
GPLv2 users (there are users that pick old gnureadline GPLv2 around).

If there are known incompatibilities, I think (not speaking on behalf of
Christos) it would be best to contribute patches with rationale. Generic
call for compatibility might not work well.



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

Re: [lldb-dev] issue with lldb9 and python3.5

[Pavel Labath via lldb-dev]

On 29/10/2019 21:40, Christos Zoulas wrote:

On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
-- Subject: Re: [lldb-dev] issue with lldb9 and python3.5

| On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
| > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
| >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
| >
| > I investigated the bug yesterday, and filled some of my discoveries in
| >
| >  https://bugs.llvm.org/show_bug.cgi?id=43830
| >
| > TLDR: libpython uses libreadline and lldb uses libedit, and that's a mess.
|
| Hey Christos,
|
| could I bother you to take a look at this python PR
| , and the related lldb bug
| ?
|
| The executive summary is that there is an incompatibility between
| readline and its libedit emulation, which python needs to work around.
| Is there any way this can be fixed in libedit?
|
| I guess the presence of the workaround will make the fix tricky, because
| then the workaround will be wrong for the "fixed" libedit, but it's
| still probably worth it to try to resolve this somehow.
|
| WDYT?

I don't know what I have to do here. Can someone explain to me what the
issue is?


I haven't dug into this (maybe Serge can explain in more detail), but I 
think this comment (Modules/readline.c in python sources) gives a 
general overview of the problem. Ignore the "On OSX" part, the same 
should apply to any OS.


/*
 * It is possible to link the readline module to the readline
 * emulation library of editline/libedit.
 *
 * On OSX this emulation library is not 100% API compatible
 * with the "real" readline and cannot be detected at compile-time,
 * hence we use a runtime check to detect if we're using libedit
 *
 * Currently there is one known API incompatibility:
 * - 'get_history' has a 1-based index with GNU readline, and a 0-based
 *   index with older versions of libedit's emulation.
 * - Note that replace_history and remove_history use a 0-based index
 *   with both implementations.
 */

Furthermore, you can probably look at every instance of 
if(using_libedit_emulation) in that file (or via this link 
), 
as each one indicates a workaround for some libedit incompatibility. It 
looks like not all of them are still relevant, as it seems some of them 
are there just for the sake of old libedit bugs which have since been 
fixed, but it looks like at least some of them are. Serge, can you tell 
what exactly was the problem which caused the crash?


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