<div dir="ltr">Hi,<div><br></div><div>It was just theoretical issue I speculated about, because I was trying to find reason why Unwind ThreadPlan for any other thread than thread group leader fails - and this seems to be already created and cached.</div>
<div><br></div><div>If you want to give it a shot, I'll attach one of my puppets (10 threads, doing nothing but sleep).</div><div>Also I use bfd linker so it has nothing to do with gold in my case.</div><div><br></div>
<div>core was created by kernel (ulimit -c unlimited; kill -3 IIRC)</div><div><br></div><div>Please note strange backtraces (clearly .text is not accessible):</div><div><br></div><div><div>(lldb) target create a.out -c core.9025</div>
<div>Core file '/home/prak/soft/test/core.9025' (x86_64) was loaded.</div><div>Process 0 stopped</div><div>* thread #1: tid = 0, 0x00007fddcd16b4a2 libpthread.so.0`pthread_join + 162, name = 'a.out', stop reason = signal SIGQUIT</div>
<div> frame #0: 0x00007fddcd16b4a2 libpthread.so.0`pthread_join + 162</div><div>libpthread.so.0`pthread_join + 162:</div><div>-> 0x7fddcd16b4a2: addb %al, (%rax)</div><div> 0x7fddcd16b4a4: addb %al, (%rax)</div>
<div> 0x7fddcd16b4a6: addb %al, (%rax)</div><div> 0x7fddcd16b4a8: addb %al, (%rax)</div><div> thread #2: tid = 1, 0x00007fddcc867aad libc.so.6, stop reason = signal SIGQUIT</div><div> frame #0: 0x00007fddcc867aad libc.so.6</div>
<div>libc.so.6`??? + 45:</div><div>-> 0x7fddcc867aad: addb %al, (%rax)</div><div><br></div><div>libc.so.6`??? + 47:</div><div> 0x7fddcc867aaf: addb %al, (%rax)</div><div><br></div><div>libc.so.6`??? + 49:</div>
<div> 0x7fddcc867ab1: addb %al, (%rax)</div><div><br></div><div>libc.so.6`??? + 51:</div><div> 0x7fddcc867ab3: addb %al, (%rax)</div><div> thread #3: tid = 2, 0x00007fddcc867aad libc.so.6, stop reason = signal SIGQUIT</div>
<div> frame #0: 0x00007fddcc867aad libc.so.6</div><div><br></div><div>and so on it goes for other threads, what looks in memory like 0x00 ...</div><div><br></div><div>We managed to unwind main thread though.</div><div>
<br></div><div>bt</div><div>* thread #1: tid = 0, 0x00007fddcd16b4a2 libpthread.so.0`pthread_join + 162, name = 'a.out', stop reason = signal SIGQUIT</div><div> * frame #0: 0x00007fddcd16b4a2 libpthread.so.0`pthread_join + 162</div>
<div> frame #1: 0x0000000000469c77 a.out`std::thread::join() + 39</div><div> frame #2: 0x0000000000433e0b a.out`main + 162 at main.cc:30</div><div> frame #3: 0x00007fddcc7d2b05 libc.so.6`__libc_start_main + 245</div>
<div> frame #4: 0x0000000000433b81 a.out`_start + 41</div><div>(lldb) thread 2</div><div>invalid command 'thread 2'</div><div>(lldb) thread select 2</div><div>* thread #2: tid = 1, 0x00007fddcc867aad libc.so.6, stop reason = signal SIGQUIT</div>
<div> frame #0: 0x00007fddcc867aad libc.so.6</div><div>libc.so.6`??? + 45:</div><div>-> 0x7fddcc867aad: addb %al, (%rax)</div><div><br></div><div>libc.so.6`??? + 47:</div><div> 0x7fddcc867aaf: addb %al, (%rax)</div>
<div><br></div><div>libc.so.6`??? + 49:</div><div> 0x7fddcc867ab1: addb %al, (%rax)</div><div><br></div><div>libc.so.6`??? + 51:</div><div> 0x7fddcc867ab3: addb %al, (%rax)</div><div><br></div><div>* thread #2: tid = 1, 0x00007fddcc867aad libc.so.6, stop reason = signal SIGQUIT</div>
<div> frame #0: 0x00007fddcc867aad libc.so.6</div><div>libc.so.6`??? + 45:</div><div>-> 0x7fddcc867aad: addb %al, (%rax)</div><div><br></div><div>libc.so.6`??? + 47:</div><div> 0x7fddcc867aaf: addb %al, (%rax)</div>
<div><br></div><div>libc.so.6`??? + 49:</div><div> 0x7fddcc867ab1: addb %al, (%rax)</div><div><br></div><div>libc.so.6`??? + 51:</div><div> 0x7fddcc867ab3: addb %al, (%rax)</div><div>image dump sections</div><div>
Dumping sections for 6 modules.</div><div>Sections for '/home/prak/soft/test/a.out' (x86_64):</div><div> SectID Type Load Address File Off. File Size Flags Section Name</div>
<div> ---------- ---------------- --------------------------------------- ---------- ---------- ---------- ----------------------------</div><div> ...</div><div> 0x0000000e code [0x0000000000433840-0x000000000048b7b2) 0x00033840 0x00057f72 0x00000006 a.out..text</div>
<div> </div><div>....</div><div><br></div><div>Sections for '/usr/lib/libc.so.6' (x86_64):</div><div> SectID Type Load Address File Off. File Size Flags Section Name</div>
<div> ---------- ---------------- --------------------------------------- ---------- ---------- ---------- ----------------------------</div><div>....</div><div> 0x0000000d code [0x00007fddcc7d0490-0x00007fddcc8fb253) 0x0001f490 0x0012adc3 0x00000006 libc.so.6..text</div>
<div>....</div><div><br></div><div>(lldb) memory read 0x0000000000433840</div><div>0x00433840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</div><div>0x00433850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</div>
<div>(lldb) x 0x00007fddcceb9510</div><div>0x7fddcceb9510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</div><div>0x7fddcceb9520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</div>
<div><br></div></div><div>Other sections from ELF's are not there too.</div><div><br></div><div>Some single threaded program like /usr/bin/sleep fail with core created by linux kernel, yet fine while created by gcore (may it add .text section to core? - x <address of .text> seems fine then)</div>
<div><br></div><div>I've noticed that all Target::ReadMemory and friends go directly to Process instead of trying to read from Modules.</div><div>That's probably no probably no problem for plugins like POSIXProcess and derived since those have everything mapped in memory, and can read it anyway.</div>
<div><br></div><div>Today I won't pursue it any more, since it is past my bedtime already, but I'll tinker with that bit more probably during weekend.</div><div><br></div><div>Thanks,</div><div>/Piotr</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-02-20 0:16 GMT+01:00 Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>[Moving LLVM to BCC and adding lldb-dev]<br></div><div><br></div>Hi Piotr!<div><br></div><div><div>Thanks for the note.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">
<div class="">
On Wed, Feb 19, 2014 at 2:54 PM, Piotr Rak <span dir="ltr"><<a href="mailto:piotr.rak@gmail.com" target="_blank">piotr.rak@gmail.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>But when we are requested to do read at boundary of two such not merged VMRanges, we will read correct data from from file to the end of 'last_entry->data.GetRangeEnd()' and then we fill rest with '\0'.</div>
<div>I think that we should split our requested read operation, to all such ranges in this case.</div><div><br></div><div>Is that correct?</div><div><br></div></div></blockquote><div><br></div></div><div>For the elf core file support, each of those memory regions represent a memory segment of the elf file. I don't *think* you should be having any memory objects which span across segments. So while it might be true that a request for a contiguous range of VM memory starts off in one segment's VM map entry and might zero fill if it would cover multiple segments that were not merged, I'm not sure what would be driving the need to do that.</div>
<div><br></div><div>What is the scenario where the need to read memory over multiple segments is showing up?</div><div><br></div><div>If we did need to do it, I think you are right in that we'd need to merge reads from each of the VM regions that overlapped with the read request.</div>
<div><br></div><div>Let me know what you find!</div><div><br></div><div>Thanks,</div><div>Todd <span class="HOEnZb"><font color="#888888"><br></font></span></div></div><span class="HOEnZb"><font color="#888888"><div>-- <br>
</div><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'">
<tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px">
Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34)">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</font></span></div></div></div>
</blockquote></div><br></div>