From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by mx.groups.io with SMTP id smtpd.web10.8178.1584731660610690098 for ; Fri, 20 Mar 2020 12:14:21 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=NE/yKMq9; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 02KIvnVJ021111; Fri, 20 Mar 2020 12:14:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=6tDSaoquj9vl0boeXSS6vVFZuz5veIXhSWUaYg6WNA8=; b=NE/yKMq9p/UEfBFU3recGCpq4Wt+ujZq336LY3YFdWn/jDWKjHsq0CnWlzoOEcBOOFqq ZpfkSzGN+Pghcs555gl3+zk0onbw3E0zBx+Mlv9cbGAlKOPOmrh7cYZQs2p+2x0XUSJU pJjnqS9nAUUQjkv24KJb1wF3onTtcKZax1Xr+8/G2jx7y8SMPc5RVfQEkgWCJ0u3XrdM 5h/MvydVMIXbhhxx72rIymgZItCuaeqOCzk3pxpOZAc1gsnbZgd8mh9NHggQ+YaqLe1g VPcjcjbqLDWkRcpIt5sHKsbnUW7zoW5PIbD2UWv6KR8++qTOAlhvIZ2VrP2by7fGTySt dA== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2yruxvfc77-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 Mar 2020 12:14:19 -0700 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q7I0027BARUDWA0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Fri, 20 Mar 2020 12:14:18 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q7I00800ABB9B00@nwk-mmpp-sz11.apple.com>; Fri, 20 Mar 2020 12:14:18 -0700 (PDT) X-Va-A: X-Va-T-CD: 2c323b19c9bf43c24bf8f3f2bb9cbf14 X-Va-E-CD: 36a32cfa42a5ae8aa02473601c03cec7 X-Va-R-CD: d2d46cdd9ed31419d4eb89636f43916d X-Va-CD: 0 X-Va-ID: 8a97c825-aed0-413a-8463-792c529cf84c X-V-A: X-V-T-CD: 2c323b19c9bf43c24bf8f3f2bb9cbf14 X-V-E-CD: 36a32cfa42a5ae8aa02473601c03cec7 X-V-R-CD: d2d46cdd9ed31419d4eb89636f43916d X-V-CD: 0 X-V-ID: ca7578af-d900-4fd9-ac11-fbdc6157acfa X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.645 definitions=2020-03-20_06:2020-03-20,2020-03-20 signatures=0 Received: from [17.235.37.239] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q7I00CBKARR4R40@nwk-mmpp-sz11.apple.com>; Fri, 20 Mar 2020 12:14:17 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <7E18AD8F-9A44-45FE-A8C8-CE06A6328930@apple.com> MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] CLANGPDB binary debugging Date: Fri, 20 Mar 2020 12:14:15 -0700 In-reply-to: <9804C565-0C9E-4778-92A7-06EA6AD8D694@ispras.ru> Cc: "Gao, Liming" , =?utf-8?Q?Marvin_H=C3=A4user?= To: devel@edk2.groups.io, cheptsov@ispras.ru References: <9804C565-0C9E-4778-92A7-06EA6AD8D694@ispras.ru> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.645 definitions=2020-03-20_06:2020-03-20,2020-03-20 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_CD2505D4-E36D-40C1-865A-3071072FD8FC" --Apple-Mail=_CD2505D4-E36D-40C1-865A-3071072FD8FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 20, 2020, at 8:13 AM, Vitaly Cheptsov wrote: >=20 > Hello, >=20 > We noticed that the original bugzilla, which intended to add new LLVM to= olchain support[1], also wanted to bring ELF format support with DWARF debu= gging information. For some reason this did not make its way into EDK II, a= nd we are currently wondering, how can one debug binaries built with LLVM 9= .0. >=20 > For macOS and XCODE5 toolchain we use GDB scripts based on Andrei Warken= tin=E2=80=99s work, which allow us to integrate with QEMU and VMware[2]. It= is likely that they should work with little to no work on Linux with CLANG= 38/GCC5 with GDB once again. However, CLANGPDB apparently is using PDB debu= gging information, which I believe is not handled with GDB. >=20 > Could you please provide the details on the matter and let us know about= the recommended route? > =E2=80=94 Is dropping CLANGELF just a temporary measure and it should be= resubmitted again? > =E2=80=94 Should LLDB, which seems to be aware of PDB, be used instead o= f GDB, when building with CLANGPDB? If so, did anybody try that? >=20 Vitaly, I've not tried the CLANGPDB path, but if you want to connect lldb to QEMU = you need to set plugin.process.gdb-remote.target-definition-file [1] to [2= ].=20 [1] lldb -o "settings set plugin.process.gdb-remote.target-definition-fil= e x86_64_target_definition.py" -o "gdb-remote 9000" [2] https://github.com/llvm-mirror/lldb/blob/master/examples/python/x86_64= _target_definition.py Thanks, Andrew Fish > Thanks! >=20 > Best regards, > Vitaly >=20 > [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3D1603 > [2] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts= /gdb_uefi.py >=20 >=20 --Apple-Mail=_CD2505D4-E36D-40C1-865A-3071072FD8FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 20, 2= 020, at 8:13 AM, Vitaly Cheptsov <cheptsov@ispras.ru> wrote:

Hell= o,

We noticed that the = original bugzilla, which intended to add new LLVM toolchain support[1], als= o wanted to bring ELF format support with DWARF debugging information. = ;For some reason this= did not make its way into EDK II, and we are currently wondering, how can = one debug binaries built with LLVM 9.0.

=
For m= acOS and XCODE5 toolchain we use GDB scripts based on Andrei Warkentin=E2=80=99s work, which allow us to integrate with Q= EMU and VMware[2]. It is likely that they should work with little to no wor= k on Linux with CLANG38/GCC5 with GDB once again. However, CLANGPDB apparen= tly is using PDB debugging information, which I believe is not handled with= GDB.

Coul= d you please provide the details on the matter and let us know about the re= commended route?
=E2=80=94 Is dropping CLANGELF just a= temporary measure and it should be resubmitted again?
=E2=80=94 Shoul= d LLDB, which seems to be aware of PDB, be used instead of GDB, when buildi= ng with CLANGPDB? If so, did anybody try that?
=

Vitaly,

I've not tried the CLANGPDB path, but if yo= u want to connect lldb to QEMU you need to set  plugin.process.gdb-rem= ote.target-definition-file [1] to [2]. 

[1]  lldb -o "settings set plugin.process.gdb-remote.target= -definition-file x86_64_target_definition.py" -o "gdb-remote 9000"
[2] https://github.com/llvm-mirro= r/lldb/blob/master/examples/python/x86_64_target_definition.py

Thanks,

And= rew Fish

Thanks!

Best regards,
Vitaly<= /font>

[1] <= a href=3D"https://bugzilla.tianocore.org/show_bug.cgi?id=3D1603" class=3D""= >https://bugzilla.tianocore.org/show_bug.cgi?id=3D1603
[2] https://github.com/acidanthera= /OpenCorePkg/blob/master/Debug/Scripts/gdb_uefi.py


--Apple-Mail=_CD2505D4-E36D-40C1-865A-3071072FD8FC--