[Lldb-commits] [PATCH] D130342: [LLDB][RISCV] Add register stuff and make breakpoint work

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D130342#3710299 , @Emmmer wrote:

> In D130342#3710122 , @tzb99 wrote:
>
>> In D130342#3709772 , @Emmmer wrote:
>>
>>> What is implemented:
>>>
>>> - Use the same register layout as Linux kernel and mock read/write for `x0` 
>>> register (the always zero register).
>>> - Take RISC-V `ebreak` instruction as breakpoint trap code, so our 
>>> breakpoint works as expected now.
>>> - Refactor some duplicate code.
>>>
>>> Further work:
>>>
>>> - RISC-V does not support hardware single stepping yet. A software 
>>> implementation may come in future PR.
>>> - Add support for RVC extension (the trap code, etc.).
>>
>> Thank you so much for the contribution! I have few more questions. What is 
>> your qemu spec? Is it operated in the user mode or the system mode? In 
>> addition, did your cross compilation build using in-tree build or build lldb 
>> separately?
>
> I'm using qemu-system 7.0.0 and in-tree cross build.

I am sorry to bother you again, is the dwarf header file changed since the last 
diff? I noticed the title of the file is changed, and based on the observation, 
such change should be related to the RISCV64_DWARF_Registers.h file? Directly 
using the file from last diff will not compile, so I rearrange the file with 
dwarf_gpr naming convention, but seems like the functionality is not complete.




Comment at: lldb/source/Plugins/Process/Utility/RegisterInfos_riscv64.h:17
+
+#include "Utility/RISCV_DWARF_Registers.h"
+#include "lldb-riscv-register-enums.h"

Do you change the name of it since last diff?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130342/new/

https://reviews.llvm.org/D130342

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

[Lldb-commits] [PATCH] D130342: [LLDB][RISCV] Add register stuff and make breakpoint work

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D130342#3709772 , @Emmmer wrote:

> What is implemented:
>
> - Use the same register layout as Linux kernel and mock read/write for `x0` 
> register (the always zero register).
> - Take RISC-V `ebreak` instruction as breakpoint trap code, so our breakpoint 
> works as expected now.
> - Refactor some duplicate code.
>
> Further work:
>
> - RISC-V does not support hardware single stepping yet. A software 
> implementation may come in future PR.
> - Add support for RVC extension (the trap code, etc.).

Thank you so much for the contribution! I have few more questions. What is your 
qemu spec? Is it operated in the user mode or the system mode? In addition, did 
your cross compilation build using in-tree build or build lldb separately?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130342/new/

https://reviews.llvm.org/D130342

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

[Lldb-commits] [PATCH] D128250: [LLDB][RISCV]Add initial support for lldb-server.

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D128250#3698652 , @Emmmer wrote:

>> Hello:
>>
>> Thank you so much for sharing the patch files. One thing I am still curious 
>> is what the ABISysv file you are using. Would you mind also sharing the 
>> remaining patches added for the lldb-server support?
>
> I didn't add any ABISysV code before uploading this patch, and now I'm 
> struggling with the breakpoints not hit problem, and it may be related to 
> ABISysV.
> After I solve this problem, I would love to share all patches added for the 
> lldb-server support.

Cool! There is one thread talking about the RISCV ABI support: 
https://reviews.llvm.org/D62732. I tried that ABI in the RISCV file but it 
seems like the same issue happened as yours, the breakpoint cannot be stopped, 
and the lldb-server cannot show the reasonable stack frame pointer address. So 
I think the ABI support should be modified.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128250/new/

https://reviews.llvm.org/D128250

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

[Lldb-commits] [PATCH] D128250: [LLDB][RISCV]Add initial support for lldb-server.

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D128250#3661588 , @Emmmer wrote:

> This commit updates:
>
> - Add the pc register according to the implementation of gdb 
> 
> - Fix register type definition macros to pass register checks
>
> The NaN problem has been solved by D129750 
>
> At this point, we can pass all LLDBUnitTest.
>
> It may be challenging to review and merge at one time for such a large patch. 
> I would like to ask if it‘s necessary to split this patch and merge them in 
> turn.

Hello:

Thank you so much for sharing the patch files. One thing I am still curious is 
what the ABISysv file you are using. Would you mind also sharing the remaining 
patches added for the lldb-server support?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128250/new/

https://reviews.llvm.org/D128250

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

[Lldb-commits] [PATCH] D62732: [RISCV] Add SystemV ABI

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D62732#3681388 , @jasonmolenda 
wrote:

> In D62732#3680154 , @tzb99 wrote:
>
>> In D62732#2790160 , @sven wrote:
>>
>>> 
>
>
>
>>> But the unwind can not work on my machine, the issue is similar to which 
>>> @jade reported
>>>
>>>   (lldb) bt
>>>   * thread #1, stop reason = breakpoint 1.1
>>> * frame #0: 0x8022 kern`fn3 at start.c:7:8
>>>
>>> Can you reproduce this problem? Or please show me how you fix the issue, 
>>> thanks very much.
>>
>> Hi: I encountered the similar issue with the frame address showing all 1s. I 
>> tried to install libxml2-dev and wanted to recompile lldb. How did you 
>> recompile lldb? Do you cross compile or compile inside the qemu environment? 
>> If you do cross-compile, would you mind show the arguments of cmake? Thank 
>> you very much!
>>
>> PS: I use cmake arguments and followed the instructions on the lldb website 
>> to do the LLVM in-tree build. I will encounter errors if I set enable xml2 
>> to be ON:
>>
>> /usr/include/libxml2/libxml/encoding.h:31:10: fatal error: unicode/ucnv.h: 
>> No such file or directory
>>
>>   31 | #include 
>>  |  ^~~~
>>
>> compilation terminated.



In D62732#3681388 , @jasonmolenda 
wrote:

> In D62732#3680154 , @tzb99 wrote:
>
>> In D62732#2790160 , @sven wrote:
>>
>>> 
>
>
>
>>> But the unwind can not work on my machine, the issue is similar to which 
>>> @jade reported
>>>
>>>   (lldb) bt
>>>   * thread #1, stop reason = breakpoint 1.1
>>> * frame #0: 0x8022 kern`fn3 at start.c:7:8
>>>
>>> Can you reproduce this problem? Or please show me how you fix the issue, 
>>> thanks very much.
>>
>> Hi: I encountered the similar issue with the frame address showing all 1s. I 
>> tried to install libxml2-dev and wanted to recompile lldb. How did you 
>> recompile lldb? Do you cross compile or compile inside the qemu environment? 
>> If you do cross-compile, would you mind show the arguments of cmake? Thank 
>> you very much!
>>
>> PS: I use cmake arguments and followed the instructions on the lldb website 
>> to do the LLVM in-tree build. I will encounter errors if I set enable xml2 
>> to be ON:
>>
>> /usr/include/libxml2/libxml/encoding.h:31:10: fatal error: unicode/ucnv.h: 
>> No such file or directory
>>
>>   31 | #include 
>>  |  ^~~~
>>
>> compilation terminated.

Thank you! I checked the DefaultUnwindPlan on the ABISysV_riscv and found it is 
not called at all in the lldb-server process. Could this patch not work on the 
qemu system mode? I am currently using the qemu system mode. In qemu, it allows 
me to install GDB and GDB works well. However, the lldb cannot stop on the 
breakpoint and the lldb-server returns the stack frame with all 1s. By taking 
further investigation, the GetExpeditedRegisters does not work well, since it 
cannot identify the sp, fp, ra, pc registers. The fucntions called 
Handle_qMemoryRegionInfo and Handle_Memory_Read don't get called, either. So my 
suspicion might fall on either the cross-compilation issue or the insufficiency 
of the current patch. Could someone show the cross-compilation recipe, or help 
with my issue? I would really appreciate that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62732/new/

https://reviews.llvm.org/D62732

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

[Lldb-commits] [PATCH] D62732: [RISCV] Add SystemV ABI

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D62732#2790160 , @sven wrote:

> In D62732#2790087 , @luismarques 
> wrote:
>
>> In D62732#2790028 , @luismarques 
>> wrote:
>>
>>> That's surprising. I'll see if I can figure out what the issue might be. 
>>> Thanks.
>>
>> Confirmed. Something must have broken since the last patch revision. I'll 
>> see if I can figure out / fix this soon.
>
> Hi @luismarques, @jade  I have fixed the issue by install **libxml2-dev**, 
> then recompile lldb and it works.
> The cause of this issue is that LLDB doesn't send qXfer command for register 
> info which defined in qemu-gdb-stub xml if libxml2 is not installed.
> See ProcessGDBRemote.cpp::GetGDBServerRegisterInfo().
> Thank you for your help.
>
>   // query the target of gdb-remote for extended target information returns
>   // true on success (got register definitions), false on failure (did not).
>   bool ProcessGDBRemote::GetGDBServerRegisterInfo(ArchSpec _to_use) {
> // Make sure LLDB has an XML parser it can use first
> if (!XMLDocument::XMLEnabled())
>   return false;
>
> But the unwind can not work on my machine, the issue is similar to which 
> @jade reported
>
>   (lldb) bt
>   * thread #1, stop reason = breakpoint 1.1
> * frame #0: 0x8022 kern`fn3 at start.c:7:8
>
> Can you reproduce this problem? Or please show me how you fix the issue, 
> thanks very much.



In D62732#2790160 , @sven wrote:

> In D62732#2790087 , @luismarques 
> wrote:
>
>> In D62732#2790028 , @luismarques 
>> wrote:
>>
>>> That's surprising. I'll see if I can figure out what the issue might be. 
>>> Thanks.
>>
>> Confirmed. Something must have broken since the last patch revision. I'll 
>> see if I can figure out / fix this soon.
>
> Hi @luismarques, @jade  I have fixed the issue by install **libxml2-dev**, 
> then recompile lldb and it works.
> The cause of this issue is that LLDB doesn't send qXfer command for register 
> info which defined in qemu-gdb-stub xml if libxml2 is not installed.
> See ProcessGDBRemote.cpp::GetGDBServerRegisterInfo().
> Thank you for your help.
>
>   // query the target of gdb-remote for extended target information returns
>   // true on success (got register definitions), false on failure (did not).
>   bool ProcessGDBRemote::GetGDBServerRegisterInfo(ArchSpec _to_use) {
> // Make sure LLDB has an XML parser it can use first
> if (!XMLDocument::XMLEnabled())
>   return false;
>
> But the unwind can not work on my machine, the issue is similar to which 
> @jade reported
>
>   (lldb) bt
>   * thread #1, stop reason = breakpoint 1.1
> * frame #0: 0x8022 kern`fn3 at start.c:7:8
>
> Can you reproduce this problem? Or please show me how you fix the issue, 
> thanks very much.

Hi: I encountered the similar issue with the frame address showing all 1s. I 
tried to install libxml2-dev and wanted to recompile lldb. How did you 
recompile lldb? Do you cross compile or compile inside the qemu environment? If 
you do cross-compile, would you mind show the arguments of cmake? Thank you 
very much!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62732/new/

https://reviews.llvm.org/D62732

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

[Lldb-commits] [PATCH] D128250: [LLDB][RISCV]Add initial support for lldb-server.

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D128250#3676635 , @tzb99 wrote:

> In D128250#3640942 , @Emmmer wrote:
>
>> This patch change:
>>
>> - Add the recognition of architecture riscv64 in `HostInfoBase.cpp`
>> - Add the recognition of architecture riscv64 and riscv32 in 
>> `ObjectFilePECOFF.cpp`
>> - Add riscv's `ebreak` command to `Platform.cpp`
>>
>> Now lldb can debug with simple executables on `qemu-system-riscv64` and be 
>> able to attach to a `gdbserver`.
>>
>> ---
>>
>> TODO: some unittest failed
>>
>>   bash
>>   [ RUN  ] TestBase.LaunchModePreservesEnvironment
>>   
>> /home/emmmer/git/llvm-project/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:29:
>>  Failure
>>   Value of: llvm::detail::TakeExpected(ClientOr)
>>   Expected: succeeded
>> Actual: failed  (Unable to parse qRegisterInfo: generic)
>>   [  FAILED  ] TestBase.LaunchModePreservesEnvironment (662 ms)
>>   
>>   
>>   [ RUN  ] TestBase.vAttachRichError
>>   Connection established.
>>   Launched 
>> '/home/emmmer/git/llvm-project/build-cross/tools/lldb/unittests/tools/lldb-server/./environment_check'
>>  as process 1553...
>>   lldb-server-local_build
>>   Connection established.
>>   Launched 
>> '/home/emmmer/git/llvm-project/build-cross/tools/lldb/unittests/tools/lldb-server/./environment_check'
>>  as process 1556...
>>   lldb-server-local_build
>>   
>> /home/emmmer/git/llvm-project/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:60:
>>  Failure
>>   Value of: llvm::detail::TakeExpected(ClientOr)
>>   Expected: succeeded
>> Actual: failed  (Unable to parse qRegisterInfo: generic)
>>   [  FAILED  ] TestBase.vAttachRichError (364 ms)
>>
>> In riscv, the user-mode process cannot directly take the `pc` register but 
>> must obtain the pc state through `auipc`, while the `pc` register is 
>> required to exist in the test, so it failed.
>>
>> ---
>>
>>   bash
>>   [ RUN  ] DumpDataExtractorTest.Formats
>>   
>> /home/emmmer/git/llvm-project/lldb/unittests/Core/DumpDataExtractorTest.cpp:90:
>>  Failure
>>   Expected equality of these values:
>> expected
>>   Which is: "{-nan -nan nan nan}"
>> result.GetString()
>>   Which is: "{nan nan nan nan}"
>>   [  FAILED  ] DumpDataExtractorTest.Formats (25 ms)
>>
>> The reason is currently unknown, and further verification is required
>>
>> ---
>>
>> About buildbot: Unfortunately, as an individual developer, I may not have 
>> the ability to maintain a 7*24-hour compile server or even a cluster, but I 
>> will do my best to provide some test reports.
>
> Hello:
>
> I implemented the diff into my local llvm project and cross-compiled the 
> project using in-tree build with enable projects as:
> -DLLVM_ENABLE_PROJECTS="clang;lld;lldb"
>
> The project can be compiled using the "Release" mode. The lldb-server can be 
> initiated and connected to the host machine from the qemu environment. It can 
> ran the riscv binary using process continue / thread continue, but the 
> compiled lldb-server cannot get any thread information and cannot perform 
> thread step-in functionality. Then I performed the Debug mode to build the 
> project. Error occurred so the build command cannot be finished. The error 
> shows like:
>
> [3759/4081] Linking CXX shared library lib/libclang-cpp.so.15git
> FAILED: lib/libclang-cpp.so.15git 
> : && riscv-gnu-toolchain/bin/riscv64-unknown-linux-gnu-g++ -
>
> Can your lldb-server work properly on the riscv qemu environment? My question 
> might be, what is the proper recipe for cross-building the lldb-server? Or, 
> should the diff be changed to enable getting the thread instruction info of 
> the lldb-server?
>
> Thank you very much!

One more detail about the ThreadInfo: This is the strace of my lldb-server 
runing on the qemu:

recvfrom(9, "$jThreadsInfo#c1", 8192, 0, NULL, NULL) = 16
gettid()= 353
openat(AT_FDCWD, "/proc/354/task/354/comm", O_RDONLY|O_CLOEXEC) = 8
read(8, "riscvv\n", 16384)  = 7
read(8, "", 16384)  = 0
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [HUP CHLD], 8) = 0
close(8)= 0
rt_sigprocmask(SIG_SETMASK, [HUP CHLD], NULL, 8) = 0
sendto(9, "$[{\"name\":\"riscvv\",\"reason\":\"sig"..., 64, 0, NULL, 0) = 64
gettid()= 353
pselect6(10, [6 9], NULL, NULL, {tv_sec=0, tv_nsec=0}, NULL) = 1 (in [9], left 
{tv_sec=0, tv_nsec=0})
recvfrom(9, "$jThreadExtendedInfo:#b9", 8192, 0, NULL, NULL) = 24
gettid()= 353


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128250/new/

https://reviews.llvm.org/D128250

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

[Lldb-commits] [PATCH] D128250: [LLDB][RISCV]Add initial support for lldb-server.

[Tiancheng Zhang via Phabricator via lldb-commits]

tzb99 added a comment.

In D128250#3640942 , @Emmmer wrote:

> This patch change:
>
> - Add the recognition of architecture riscv64 in `HostInfoBase.cpp`
> - Add the recognition of architecture riscv64 and riscv32 in 
> `ObjectFilePECOFF.cpp`
> - Add riscv's `ebreak` command to `Platform.cpp`
>
> Now lldb can debug with simple executables on `qemu-system-riscv64` and be 
> able to attach to a `gdbserver`.
>
> ---
>
> TODO: some unittest failed
>
>   bash
>   [ RUN  ] TestBase.LaunchModePreservesEnvironment
>   
> /home/emmmer/git/llvm-project/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:29:
>  Failure
>   Value of: llvm::detail::TakeExpected(ClientOr)
>   Expected: succeeded
> Actual: failed  (Unable to parse qRegisterInfo: generic)
>   [  FAILED  ] TestBase.LaunchModePreservesEnvironment (662 ms)
>   
>   
>   [ RUN  ] TestBase.vAttachRichError
>   Connection established.
>   Launched 
> '/home/emmmer/git/llvm-project/build-cross/tools/lldb/unittests/tools/lldb-server/./environment_check'
>  as process 1553...
>   lldb-server-local_build
>   Connection established.
>   Launched 
> '/home/emmmer/git/llvm-project/build-cross/tools/lldb/unittests/tools/lldb-server/./environment_check'
>  as process 1556...
>   lldb-server-local_build
>   
> /home/emmmer/git/llvm-project/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:60:
>  Failure
>   Value of: llvm::detail::TakeExpected(ClientOr)
>   Expected: succeeded
> Actual: failed  (Unable to parse qRegisterInfo: generic)
>   [  FAILED  ] TestBase.vAttachRichError (364 ms)
>
> In riscv, the user-mode process cannot directly take the `pc` register but 
> must obtain the pc state through `auipc`, while the `pc` register is required 
> to exist in the test, so it failed.
>
> ---
>
>   bash
>   [ RUN  ] DumpDataExtractorTest.Formats
>   
> /home/emmmer/git/llvm-project/lldb/unittests/Core/DumpDataExtractorTest.cpp:90:
>  Failure
>   Expected equality of these values:
> expected
>   Which is: "{-nan -nan nan nan}"
> result.GetString()
>   Which is: "{nan nan nan nan}"
>   [  FAILED  ] DumpDataExtractorTest.Formats (25 ms)
>
> The reason is currently unknown, and further verification is required
>
> ---
>
> About buildbot: Unfortunately, as an individual developer, I may not have the 
> ability to maintain a 7*24-hour compile server or even a cluster, but I will 
> do my best to provide some test reports.

Hello:

I implemented the diff into my local llvm project and cross-compiled the 
project using in-tree build with enable projects as:
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb"

The project can be compiled using the "Release" mode. The lldb-server can be 
initiated and connected to the host machine from the qemu environment. It can 
ran the riscv binary using process continue / thread continue, but the compiled 
lldb-server cannot get any thread information and cannot perform thread step-in 
functionality. Then I performed the Debug mode to build the project. Error 
occurred so the build command cannot be finished. The error shows like:

[3759/4081] Linking CXX shared library lib/libclang-cpp.so.15git
FAILED: lib/libclang-cpp.so.15git 
: && riscv-gnu-toolchain/bin/riscv64-unknown-linux-gnu-g++ -

Can your lldb-server work properly on the riscv qemu environment? My question 
might be, what is the proper recipe for cross-building the lldb-server? Or, 
should the diff be changed to enable getting the thread instruction info of the 
lldb-server?

Thank you very much!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128250/new/

https://reviews.llvm.org/D128250

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