[lldb-dev] [Bug 23659] LLDB cannot evaluate expressions on linux if inferior is stopped in a syscall
https://llvm.org/bugs/show_bug.cgi?id=23659 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from lab...@google.com --- Looks good, thanks for fixing this. -- You are receiving this mail because: You are on the CC list for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Offset Calculations for Registers on Linux x86_64
Hi Greg Thanks for your reply. My next queries are based on the Bug 24457 that I filed 2-3 days ago. I analyzed and found the reason of this bug for x86_64-Linux platform. A solution to fix this bug requires change in the definition of macro FPR_OFFSET (defined in RegisterInfos_x86_64.h) to calculate offsets for fpr registers wrt to FPR structure (defined in *RegisterContext_x86.h*) and not wrt to UserArea structure (defined in *RegisterContextLinux_x86_64.cpp*). I am a bit unclear on your statements *"All offsets should be the global offset in the register context's data"* and "*We just require that you append all register sets together into one chunk (GPR + FPR + ...)*" in your last 2 replies. In context of this bug, do your statements mean that macro FPR_OFFSET will not be allowed to change? - Abhishek Aggarwal On Fri, Aug 14, 2015 at 6:17 PM, Greg Clayton wrote: > > > On Aug 14, 2015, at 12:25 AM, Abhishek Aggarwal > wrote: > > > > Hi > > > > As per my understanding (please correct if I am wrong): > > > > 1. There exists a file for each platform (Architecture+OS) that > calculates the offsets for that platform. e.g. > RegisterContextLinux_x86_64.cpp for x86_64 architecture on Linux OS. > > Correct. We allow register context data buffers to just mirror exactly > what the OS gives us which is usually N chunks of data representing the raw > registers as they would be gotten from the OS supplied functions (like > ptrace for reading/writing registers). > > > 2. For each platform, offset values for registers might be different > because it depends upon the way the members of structures GPR, FPR and > UserArea are organized in Platform specific file. e.g. Offset of rax will > be 80 and not 0 for RegisterContextLinux_x86_64.cpp because rax lies at > 10th position in structure GPR defined in this file. > > Yep, we adapt to the way the OS represents registers in their native > buffers. We just require that you append all register sets together into > one chunk (GPR + FPR + ...). > > > > 3. The main motive behind calculating offsets for each register is to > fetch data from the correct location in a chunk of data that a ptrace API > provides (atleast in case of Linux OS). > > Yes. Just as on MacOSX we mimic how thread_get_state(task_t task, ) > returns registers. > > > > > On Thu, Aug 13, 2015 at 6:42 PM, Greg Clayton > wrote: > > All registers are placed into one large buffer that contains everything. > All offsets should be the global offset in the register context's data. > Typically we should see: > > > > > > GPR > >rax offset 0 > >rbx offset 8 > > > > FPR > >mm0 offset 128 > >mm1 offset 160 > >... > > EXC > >fpsr offset 256 > >... > > > > > > So the offsets should be based on the offset from the start of the one > large buffer that contains all register values. > > > > > On Aug 13, 2015, at 2:26 AM, Abhishek Aggarwal via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > > > > Hello > > > > > > I have a question regarding offset calculations of registers for > x86_64 architecture. In file > source/Plugins/Process/Utility/RegisterInfos_x86_64.h: > > > > > > The macro FPR_OFFSET(reg) calculates the offset of floating point > register 'reg' with respect to 'UserArea' struct while GPR_OFFSET(reg) > calculates it wrt to 'GPR' struct. Is there any specific reason of > calculating the offsets of floating point registers wrt 'UserArea' struct > and not wrt 'FPR' struct (defined in > source/Plugins/Process/Utility/RegisterContext_x86.h) ? > > > > > > ___ > > > 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] [APT] lldb crashes on sturtup
Hello. I have installed clang and lldb from here http://llvm.org/apt/ deb http://llvm.org/apt/vivid/ llvm-toolchain-vivid main deb-src http://llvm.org/apt/vivid/ llvm-toolchain-vivid main lldb crashed on startup every time. Program received signal SIGSEGV, Segmentation fault. 0x747d2b29 in llvm::cl::Option::addArgument() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 (gdb) bt #0 0x747d2b29 in llvm::cl::Option::addArgument() () from /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 #1 0x7fffee7ce7af in global constructors keyed to a () from /usr/local/lib/python2.7/dist-packages/lldb/_lldb.so #2 0x700c4020 in __frame_dummy_init_array_entry () from /usr/local/lib/python2.7/dist-packages/lldb/_lldb.so #3 0x7fffddc8 in ?? () #4 0x7fffddd8 in ?? () #5 0x700c4258 in __frame_dummy_init_array_entry () #6 0x in ?? () Dump of assembler code for function _ZN4llvm2cl6Option11addArgumentEv: 0x747d2aea <+10>:mov%rdi,%rbx 0x747d2aed <+13>:sub$0x58,%rsp 0x747d2af1 <+17>:mov0xec4468(%rip),%rbp# 0x75696f60 0x747d2af8 <+24>:mov%fs:0x28,%rax 0x747d2b01 <+33>:mov%rax,0x48(%rsp) 0x747d2b06 <+38>:xor%eax,%eax 0x747d2b08 <+40>:callq 0x74813ad0 <_ZN4llvm21llvm_is_multithreadedEv> 0x747d2b0d <+45>:test %al,%al 0x747d2b0f <+47>:jne0x747d2cd0 <_ZN4llvm2cl6Option11addArgumentEv+496> 0x747d2b15 <+53>:test %rbp,%rbp 0x747d2b18 <+56>:je 0x747d2cde <_ZN4llvm2cl6Option11addArgumentEv+510> 0x747d2b1e <+62>:mov0x18(%rbx),%r12 0x747d2b22 <+66>:mov0xec4437(%rip),%rbp# 0x75696f60 => 0x747d2b29 <+73>:cmpb $0x0,(%r12) (gdb) i r r12 r120x0 0 Looks like a crash in static/global variable constructor. I've tried to build lldb from sources using cmake and it works like a charm. Any suggestions on how to fix that? My laptop is old and slow. That's why I prefer deb packages over building from sources. Sorry in case if I wrote to a wrong place. -- Eugene ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Offset Calculations for Registers on Linux x86_64
> On Aug 17, 2015, at 8:06 AM, Abhishek Aggarwal wrote: > > Hi Greg > > Thanks for your reply. My next queries are based on the Bug 24457 that I > filed 2-3 days ago. > > I analyzed and found the reason of this bug for x86_64-Linux platform. > > A solution to fix this bug requires change in the definition of macro > FPR_OFFSET (defined in RegisterInfos_x86_64.h) to calculate offsets for fpr > registers wrt to FPR structure (defined in RegisterContext_x86.h) and not wrt > to UserArea structure (defined in RegisterContextLinux_x86_64.cpp). > > I am a bit unclear on your statements > "All offsets should be the global offset in the register context's data" and > "We just require that you append all register sets together into one chunk > (GPR + FPR + ...)" in your last 2 replies. > > In context of this bug, do your statements mean that macro FPR_OFFSET will > not be allowed to change? The offset for each register should be the offset in the register context data buffer, so if the first FPU register currently has 128 as the offset, it shouldn't change to zero if that is the correct offset. If you are seeing issues and believe the offset should be zero, then the bug is somewhere else and needs to be fixed elsewhere. The linux plug-in might be expecting a zero based offset for some registers in some locations, but that should all be fixed within the RegisterContextLinuxx86_64 class. Greg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Moderator needed
Hello! I am looking for 1-2 volunteers to help moderate the lldb-dev and lldb-commits mailing lists. Please let me know if you can help! Thanks, Tanya ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
