Hi Daisuke,<br><br><div class="gmail_quote">On Tue, Oct 23, 2012 at 2:17 PM, HATAYAMA Daisuke <span dir="ltr"><<a href="mailto:d.hatayama@jp.fujitsu.com" target="_blank">d.hatayama@jp.fujitsu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Lei Wen <<a href="mailto:adrian.wenl@gmail.com">adrian.wenl@gmail.com</a>><br>
Subject: Re: GCORE: add directly show backtrace function in crash<br>
Date: Mon, 22 Oct 2012 15:36:47 +0800<br>
<div><div class="h5"><br>
> Hi Daisuke,<br>
><br>
> On Mon, Oct 22, 2012 at 3:29 PM, HATAYAMA Daisuke <<a href="mailto:d.hatayama@jp.fujitsu.com">d.hatayama@jp.fujitsu.com</a><br>
>> wrote:<br>
><br>
>> From: Lei Wen <<a href="mailto:adrian.wenl@gmail.com">adrian.wenl@gmail.com</a>><br>
>> Subject: GCORE: add directly show backtrace function in crash<br>
>> Date: Mon, 22 Oct 2012 12:21:49 +0800<br>
>><br>
>> > Hi Daisuke,<br>
>> ><br>
>> > I create a new option "-tT" for gcore, so that it could display bt for<br>
>> user<br>
>> > space<br>
>> > directly inside crash itself, without needing to dump a separated core<br>
>> file<br>
>> > image,<br>
>> > and analyze it in a different gdb env.<br>
>> ><br>
>> > The attached patch is directly based on below patch, and verify over ARM<br>
>> > platform.<br>
>> > <a href="http://osdir.com/ml/general/2012-10/msg32677.html" target="_blank">http://osdir.com/ml/general/2012-10/msg32677.html</a><br>
>> ><br>
>> > Before use the corresponding gcore command, we need set env in crash by:<br>
>> ><br>
>> > crash>> gdb set solib-search-path [system lib path]<br>
>> ><br>
>> > crash>> gdb file   [user space program symbol file]<br>
>> ><br>
>> > crash>> gcore -t [user space thread id]<br>
>> ><br>
>> > Thanks,<br>
>> > Lei<br>
>><br>
>> Hello Lei,<br>
>><br>
>> That must be a useful feature, but I think it's very othogonal to<br>
>> gcore command...<br>
>><br>
>> Why not releasing your own extension module separately to gcore?<br>
>><br>
><br>
> I put this function in gcore, is for gcore already provide the function to<br>
> get<br>
> the general register for user space thread. If add another module, that<br>
> part of function seems a little duplicated...<br>
><br>
<br>
</div></div>I now understand why you want to add it in gcore.<br>
<div class="im"><br>
> Also provide the gcore the capability to either dump into a core file<br>
> or directly display, user may have more choice over this. :)<br>
><br>
<br>
</div>But, users then need to do more work such as loading application's<br>
symbol files. There seems not so big difference.<br>
<br>
gdb has one symbol space only. If you load applications's symbols, it<br>
can override kernel symbols. Then, gcore might behave abnormally. Can<br>
users reset the loading of applications' symbols in any feature of<br>
gdb?<br></blockquote><div><br></div><div>Good question!</div><div>However I am not a gdb expert... Hope someone here could give a solution...</div><div>Also a silly question, since kernel runs well with user symbol, why gdb</div>
<div>could not live with the chaos?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
32-bit compability mode support? On x86-64 task can be running in<br>
32-bit comparitbility mode. If so, gdb backtrace need to do the work<br>
in 32-bit mode, I think. Does the current version covers this?<br>
<br></blockquote><div><br></div><div>No idea really...</div><div><br></div><div>Thanks,</div><div>Lei</div></div><br>