Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface
Thanks for sharing those details Ted. Regards, Ramana On Sat, Sep 23, 2017 at 2:19 AM, Ted Woodward wrote: > We treat them as 2 separate targets. We're actually running 2 separate lldb > instances - one in Android Studio, and 1 in a shell on Hexagon Linux. > > Android Studio is running on the host (x86 Linux or Windows PC). We have an > adb shell open to android on the ARM, and from there ssh to Linux on the > Hexagon. The DSP doesn't have a direct connection to the outside world; > everything goes through the ARM. > > Yes, Greg, that's lldb and lldb-server running on the DSP! > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > >> -Original Message- >> From: Ramana [mailto:ramana.venka...@gmail.com] >> Sent: Friday, September 22, 2017 6:24 AM >> To: Ted Woodward >> Cc: Greg Clayton ; lldb-dev@lists.llvm.org >> Subject: Re: [lldb-dev] lldb_private::RegisterContext vs >> lldb_private::RegisterInfoInterface >> >> If I may ask, among the options that Greg had mentioned in the earlier >> replies, >> which was the approach you have chosen? >> >> > We've done something similar in-house running on a Snapdragon with an >> > ARM and a Hexagon DSP. We use Android Studio to debug an app on the >> > ARM that sends work down to the Hexagon, running an app under Linux. >> > On the Hexagon we ran lldb, and were able to debug both apps talking to >> each other. >> >> You run lldb (client) on both ARM and Hexagon? Or you run lldb-server on the >> Hexagon and lldb (client) on ARM? Or something else other than that? >> >> On Thu, Sep 21, 2017 at 10:34 PM, Ted Woodward >> wrote: >> > We've done something similar in-house running on a Snapdragon with an >> ARM and a Hexagon DSP. We use Android Studio to debug an app on the ARM >> that sends work down to the Hexagon, running an app under Linux. On the >> Hexagon we ran lldb, and were able to debug both apps talking to each other. >> > >> > -- >> > Qualcomm Innovation Center, Inc. >> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> > a Linux Foundation Collaborative Project >> > >> >> -Original Message- >> >> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of >> >> Greg Clayton via lldb-dev >> >> Sent: Thursday, September 21, 2017 10:10 AM >> >> To: Ramana >> >> Cc: lldb-dev@lists.llvm.org >> >> Subject: Re: [lldb-dev] lldb_private::RegisterContext vs >> >> lldb_private::RegisterInfoInterface >> >> >> >> >> >> > On Sep 21, 2017, at 5:15 AM, Ramana >> >> wrote: >> >> > >> >> > Sorry, I could not respond yesterday as I was of out of office. >> >> > >> >> >> Interesting. There are two ways to accomplish this: >> >> >> 1 - Treat the CPU as one target and the GPU as another. >> >> >> 2 - Treat the CPU and GPU as one target >> >> >> >> >> >> The tricky things with solution #1 is how to manage switching the >> >> >> targets between the CPU and GPU when events happen (CPU stops, or >> >> >> GPU stops while the other is running or already stopped). We don't >> >> >> have any formal "cooperative targets" yet, but we know they will >> >> >> exist in the future (client/server, vm code/vm debug of vm code, >> >> >> etc) so we will be happy to assist with questions if and when you get >> there. >> >> > >> >> > I was going along the option #1. Would definitely post here with >> >> > more questions as I progress, thank you. Fortunately, the way >> >> > OpenVX APIs work is, after off-loading the tasks to GPU, they will >> >> > wait for the GPU to complete those tasks before continuing further. >> >> > And in our case, both CPU and GPU can be controlled separately. >> >> > Given that, do you think I still need to bother much about "cooperative >> targets"? >> >> >> >> If you just want to make two targets that know nothing about each >> >> other, then that is very easy. Is that what you were asking? >> >> >> >> > >> >> >> GPU debugging is tricky since they usually don't have a kernel or >> >> >> anything running on the hardware. Many examples I have seen so far >> >> >> will set a breakpoint in the program at some point by compiling >> >> >> the code with a breakpoint inserted, run to that breakpoint, and >> >> >> then if the user wants to continue, you recompile with breakpoints >> >> >> set at a later place and re-run the entire program again. Is your GPU >> >> >> any >> different? >> >> > >> >> >> We also discussed how to single step in a GPU program. Since >> >> >> multiple cores on the GPU are concurrently running the same >> >> >> program, there was discussion on how single stepping would work. >> >> >> If you are stepping and run into an if/then statement, do you walk >> >> >> through the if and the else at all times? One GPU professional was >> >> >> saying this is how GPU folks would want to see single stepping >> >> >> happen. So I think there is a lot of stuff we need to think about when >> debugging GPUs in
Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler type
After your e-mail I questioned if that was the right place to fix that, and it
wasn’t.
The unwinder was not being created to PPC64le, and it set the CFA with wrong
value.
Thanks anyway!
Leonardo Bianconi.
From: Greg Clayton [mailto:clayb...@gmail.com]
Sent: terça-feira, 19 de setembro de 2017 15:09
To: Leonardo Bianconi
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler type
So you need to fix "DW_OP_call_frame_cfa" so it creates the same kind of value
on the expression stack as "DW_OP_reg31" does. I am guessing that "DW_OP_reg31"
will have a Value that whose value is "eValueTypeScalar". Verify this and
change "DW_OP_call_frame_cfa" to match. We want the Scalar gotten by:
Scalar value;
if (frame->GetFrameBaseValue(value, error_ptr)) {
To be the same kind of value. Seems the expression parsing code that uses
"DW_OP_call_frame_cfa" is doing the wrong thing by setting the value to a load
address type.
On Sep 19, 2017, at 10:51 AM, Leonardo Bianconi
mailto:leonardo.bianc...@eldorado.org.br>>
wrote:
-Original Message-
From: Greg Clayton [mailto:clayb...@gmail.com]
Sent: terça-feira, 19 de setembro de 2017 12:33
To: Leonardo Bianconi
mailto:leonardo.bianc...@eldorado.org.br>>
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler
type
On Sep 19, 2017, at 4:10 AM, Leonardo Bianconi
mailto:leonardo.bianc...@eldorado.org.br>>
wrote:
Some more details:
I'm part of the team that is working in LLDB to enable PPC64le architecture, so
I'm running my test in a Power8 machine.
When compiling the code with clang, it works, the issue happen when compiling
with gcc, which generates a different debug information content.
Talking a bit about the power stack frame, it is organized this way:
Suppose that you have two functions a() and b() and a calls b, then the frames
will be like this:
high address
+-+
| ...| // frame of a
| ...|
| ...|
| ...|
| ...|
| back chain| // r31 and r1 points here when running function a
+-+
| ...| // frame of b
|variable address |
| ...|
| ...|
| ...|
| back chain| // r31 and r1 points here when running function b
+-+
low address
The debug information related to find the variable with clang is:
<2><6ce>: Abbrev Number: 27 (DW_TAG_variable)
<6cf> DW_AT_location: 3 byte block: 91 f0 0 (DW_OP_fbreg: 112)
<6d3> DW_AT_name: (indirect string, offset: 0x1cf): a
<6d7> DW_AT_decl_file : 5
<6d8> DW_AT_decl_line : 6
<6d9> DW_AT_type: <0x1bf>
<2><6dd>: Abbrev Number: 0
<1><6de>: Abbrev Number: 0
<1><6b5>: Abbrev Number: 26 (DW_TAG_subprogram)
<6b6> DW_AT_low_pc : 0x1630
<6be> DW_AT_high_pc : 0x88
<6c2> DW_AT_frame_base : 1 byte block: 6f(DW_OP_reg31 (r31))
<6c4> DW_AT_name: (indirect string, offset: 0x1ca): main
<6c8> DW_AT_decl_file : 5
<6c9> DW_AT_decl_line : 5
<6ca> DW_AT_type: <0x1bf>
<6ce> DW_AT_external: 1
Which uses the r31 (DW_OP_reg31) and a positive offset (112) to find it, which
is ok, as it does not need to read the memory using the address in the r31
register.
The issue happen when using the debug information generated by gcc, which
is:
<2><9e>: Abbrev Number: 5 (DW_TAG_variable)
<9f> DW_AT_name: a
DW_AT_decl_file : 1
DW_AT_decl_line : 6
DW_AT_type: <0x3b>
DW_AT_location: 2 byte block: 91 5c (DW_OP_fbreg: -36)
<1><81>: Abbrev Number: 4 (DW_TAG_subprogram)
<82> DW_AT_external: 1
<82> DW_AT_name: (indirect string, offset: 0xe): main
<86> DW_AT_decl_file : 1
<87> DW_AT_decl_line : 5
<88> DW_AT_type: <0x3b>
<8c> DW_AT_low_pc : 0x840
<94> DW_AT_high_pc : 0xf8
<9c> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<9e> DW_AT_GNU_all_tail_call_sites: 1
Here, it says to use the "DW_OP_call_frame_cfa", that is correctly executed in
the LLDB, obtaining the content of r31 and setting it as "
lldb_private::Value::eValueTypeLoadAddress", which means the data it is looking
for is located in the address obtained in the r31, and it need to be read from
memory. If the address was correctly read, it would point to the back chain of
the
previous frame, and the variable would be found, as the offset is negative
(-36),
so ("previous back chain address" - 36) is the correct variable address.
My code is very simple:
=
#include
#include
int main(void) {
int a = 2;
printf("a address: %p \n", (void*)&a);
printf("a = %d \n", a);
return 0;
}
=
And I'm using the commands:
gcc -O0 -ggdb stest.cpp (gcc ver
Re: [lldb-dev] Session Volunteers for Hackers Lab Needed!
I have > On Sep 24, 2017, at 1:25 AM, Tanya Lattner via lldb-dev > wrote: > > All, > > We need volunteers for the Hacker’s Lab at the upcoming 2017 LLVM Developers’ > Meeting! The Hacker’s Lab is for small groups to form to discuss topics or > work on problems. Please let me know ASAP if you will able to volunteer so I > can add your topic to the online listing and make appropriate signs. > > The Hackers Lab is split into 1.5 hour sessions. During each session, the > Hackers Lab will focus on specific topics. Each table (~15) in the room will > have a sign on it to represent a sub-project or area of LLVM. This will help > newcomers and even active developers congregate together on specific topics. > Many of the tables will have an easel for informal discussions. > > In addition to labeling tables, we are asking for volunteers to represent a > sub-project or topic related to the meeting. These volunteers should be > knowledgeable about the sub-project/topic and able to answer some basic > questions or point people to the right developer to talk to. If volunteers > want to go a step further, they could prepare a list of bugs that groups > could work on during the Hackers Lab. This is very open ended in what the > leader of the table can do, but the main goal is to provide a space for > developers’ to meet and find each other who are interested in a specific > topic or sub-project. > > I’ve gone through many of the Code Owners files to try to find topics, and > here is a list I have started.. but really it depends on who volunteers :) > > LLVM > Backends, Code Generation, Register Allocation, Machine Code Layer, ISel > LLDB, Debug Info, DWARF > LTO > Polly > MCJIT > Mid-level optimizations, pass manager, loop optimizations, etc > TableGen > Sanitizers > Windows support > Exception handling > lld > > Clang, Libs, & Frontend tools > Clang - parsing, llvm ir generation, etc > Static Analyzer > OpenCL > Clang Tools - clang tidy, clang rename > parallel-libs > Open MP > libC++ > llgo > > I know this may be a bit confusing.. but it really doesn’t require much work > if you don’t want it to. Ideally, I would love some Code Owners to fill the > roles, but I realize not all will be attending. > > Please let me know ASAP if you are interested! In the rare event I have too > many volunteers, we may combine topics at tables. > > Thanks, > Tanya > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] 2017 LLVM Dev Meeting - Schedule Online, Registration Closing & Room Block Expiring
All, The 2017 LLVM Developers’ Meeting registration will be closing soon! Please make sure you are registered and tell your friends that they don’t want to miss the opportunity to attend the largest gathering of LLVM Developers. https://llvm.org/devmtg/2017-10/ https://www.eventbrite.com/e/2017-llvm-developers-meeting-bay-area-tickets-35155516095 In addition, the room block for the event ends tomorrow September 26th! Details here: https://llvm.org/devmtg/2017-10/#logistics We have an AMAZING program this year. The schedule is now online: https://2017llvmdevmtg.sched.com Meeting other LLVM developers face to face is invaluable! We hope to see you there. Thanks, Tanya ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
