Page MenuHomePhabricator

tzb99 (Tiancheng Zhang)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 25 2022, 9:12 AM (10 w, 3 d)

Recent Activity

Thu, Sep 8

tzb99 added a comment to rGff7b876aa75d: [LLDB][RISCV] Add more instruction decode and execute for….

CMake complains a lot at line 201 on

lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp

Should we update the cmake file in some places to enable the C++17 language standard? I add the statement such as

Thu, Sep 8, 10:11 AM · Restricted Project

Aug 31 2022

tzb99 added a comment to D132789: [LLDB][RISCV] Add more instruction decode and execute for EmulateInstructionRISCV.

Upon this change, My lldb logging changes a bit. The instruction is not shown anymore, but stepping is still working. Is it as expected?

* thread #1, name = 'test.o', stop reason = signal SIGSTOP
    frame #0: 0x0000000000010528

I tried to reproduce but failed.
Could you please provide more information?
(for example: what is written in main, why use .o for debugging, and the command operations executed in lldb)

Sure. My testing script is:

#include<stdio.h>
void fun2() {
	printf("Enter fun2\n");
}
int fun1() {
	printf("Enter fun1\n");
	fun2();
	return 10;}

int main(int argc, char **argv) {
	int a = fun1();
	int b = 15;
       	printf("hello world\n");
	return 0;
}

So which file format should be used for debugging? My command option on the client side is:

lldb-server g 0.0.0.0:2345 test.o

On the lldb (x86) side is:

lldb
gdb-remote 2345
s

The objdump of my test.o file is:

0000000000010528 <_start>:
   10528:       02e000ef                jal     ra,10556 <load_gp>
   1052c:       87aa                    mv      a5,a0
   1052e:       00000517                auipc   a0,0x0
   10532:       14650513                addi    a0,a0,326 # 10674 <main>
   10536:       6582                    ld      a1,0(sp)
   10538:       0030                    addi    a2,sp,8
   1053a:       ff017113                andi    sp,sp,-16
   1053e:       00000697                auipc   a3,0x0
   10542:       68068693                addi    a3,a3,1664 # 10bbe <__libc_csu_init>
   10546:       00000717                auipc   a4,0x0

My compilation flavor should be:

riscv64-unknown-linux-gnu-gcc -g -o test.o hello.c \
-static -static-libgcc -static-libstdc++ -march=rv64imafd

Please let me know if you need more information!

I coiped your test code to tzb.c

(on x86)

$ riscv64-unknown-linux-gnu-gcc -g -o tzb tzb.c \
  -static -static-libgcc -static-libstdc++ -march=rv64imafd

PS: -o usage is: -o <file>, it means place the output into <file>.


(on qemu-system-riscv64)

$ lldb
(lldb) gdb-remote 8888

(lldb) Process 5933 stopped
* thread #1, name = 'tzb', stop reason = signal SIGSTOP
    frame #0: 0x0000000000010528 tzb`_start at start.S:50
warning: This version of LLDB has no plugin for the language "assembler". Inspection of frame variables will be limited.

Then I tried to read DWARF in tzb, and dwarfdump report DW_AT_language is DW_LANG_Mips_Assembler, but DW_AT_language should be DW_LANG_C99.


It may be a bug caused by riscv-gnu-toolchain, and we can use this to avoid it.

(on qemu-system-riscv64)

$ gcc -g -o tzb tzb.c \
  -static -static-libgcc -static-libstdc++ -march=rv64imafd

$ lldb-server g 0.0.0.0:2345 tzb
Launched 'tzb' as process 6839...
lldb-server-local_build

(Switch to another tab)

$ lldb
(lldb) gdb-remote 2345

(lldb) Process 6839 stopped
* thread #1, name = 'tzb', stop reason = signal SIGSTOP
    frame #0: 0x0000000000010584 tzb`_start
tzb`_start:
->  0x10584 <+0>:  jal    48                    <--|
    0x10588 <+4>:  mv     a5, a0                <--|
    0x1058c <+8>:  auipc  a0, 121               <--|
    0x10590 <+12>: ld     a0, -980(a0)          <--| as expected
(lldb)

Then you can set breakpoints and go to where you want.


I copied some DWARF info that may be useful:

in cross-build elf file:

.debug_info

COMPILE_UNIT<header overall offset = 0x00000000>:
< 0><0x0000000c>  DW_TAG_compile_unit
                    DW_AT_stmt_list             0x00000000
                    DW_AT_low_pc                0x00010528
                    DW_AT_high_pc               <offset-from-lowpc>0x00000042
                    DW_AT_name                  ../sysdeps/riscv/start.S
                    DW_AT_comp_dir              /home/emmmer/git/riscv-gnu-toolchain/glibc/csu
                    DW_AT_producer              GNU AS 2.38
                    DW_AT_language              DW_LANG_Mips_Assembler

in native-build elf file:

.debug_info

COMPILE_UNIT<header overall offset = 0x00000000>:
< 0><0x0000000b>  DW_TAG_compile_unit
                    DW_AT_producer              GNU C17 10.3.1 -march=rv64imafd -mabi=lp64d -g
                    DW_AT_language              DW_LANG_C99
                    DW_AT_name                  tzb.c
                    DW_AT_comp_dir              /root
                    DW_AT_low_pc                0x000106ac
                    DW_AT_high_pc               <offset-from-lowpc>188
                    DW_AT_stmt_list             0x00000000
Aug 31 2022, 2:12 PM · Restricted Project, Restricted Project

Aug 30 2022

tzb99 added a comment to D132789: [LLDB][RISCV] Add more instruction decode and execute for EmulateInstructionRISCV.

Upon this change, My lldb logging changes a bit. The instruction is not shown anymore, but stepping is still working. Is it as expected?

* thread #1, name = 'test.o', stop reason = signal SIGSTOP
    frame #0: 0x0000000000010528

I tried to reproduce but failed.
Could you please provide more information?
(for example: what is written in main, why use .o for debugging, and the command operations executed in lldb)

Aug 30 2022, 4:06 PM · Restricted Project, Restricted Project

Aug 29 2022

tzb99 added a comment to D132789: [LLDB][RISCV] Add more instruction decode and execute for EmulateInstructionRISCV.

Upon this change, My lldb logging changes a bit. The instruction is not shown anymore, but stepping is still working. Is it as expected?

Aug 29 2022, 5:24 PM · Restricted Project, Restricted Project

Aug 9 2022

tzb99 added a comment to D130342: [LLDB][RISCV] Add riscv register definition and read/write.

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.

Aug 9 2022, 9:58 PM · Restricted Project, Restricted Project
tzb99 added a comment to D130342: [LLDB][RISCV] Add riscv register definition and read/write.

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.).
Aug 9 2022, 9:06 AM · Restricted Project, Restricted Project

Aug 4 2022

tzb99 added a comment to D128250: [LLDB][RISCV]Add initial support for lldb-server..

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.

Aug 4 2022, 9:59 AM · Restricted Project, Restricted Project

Aug 3 2022

tzb99 added a comment to D128250: [LLDB][RISCV]Add initial support for lldb-server..

This commit updates:

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.

Aug 3 2022, 10:02 PM · Restricted Project, Restricted Project
tzb99 added a comment to D62732: [RISCV] Add SystemV ABI.

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: 0x0000000080000022 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 <unicode/ucnv.h>
   |          ^~~~~~~~~~~~~~~~

compilation terminated.

Aug 3 2022, 5:14 PM · Restricted Project, Restricted Project

Jul 26 2022

tzb99 added a comment to D62732: [RISCV] Add SystemV ABI.

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 &arch_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: 0x0000000080000022 kern`fn3 at start.c:7:8

Can you reproduce this problem? Or please show me how you fix the issue, thanks very much.

Jul 26 2022, 10:07 AM · Restricted Project, Restricted Project

Jul 25 2022

tzb99 added a comment to D128250: [LLDB][RISCV]Add initial support for lldb-server..

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!

Jul 25 2022, 2:14 PM · Restricted Project, Restricted Project
tzb99 added a comment to D128250: [LLDB][RISCV]Add initial support for lldb-server..

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.

Jul 25 2022, 9:34 AM · Restricted Project, Restricted Project