Hi , There are 4 ways to get the function call stack in the GDB Internals Manual. https://sourceware.org/gdb/papers/unwind.html For x86_64, does GDB get information by parsing the .eh_frame section? Or just get the call stack by Parse the function prologues.
On 8/16/22 08:43, hilbert via Gdb wrote:
> Hi ,
> There are 4 ways to get the function call stack in the GDB Internals Manual. https://sourceware.org/gdb/papers/unwind.html
> For x86_64, does GDB get information by parsing the .eh_frame section? Or just get the call stack by Parse the function prologues.
>
>
>
I'd say mostly 1 and 2. 1 is usually used with functions without debug information. 2 is used when there is debug information.
@Luis Machado
Thank you very much .
What does the sentence “functions without debug information”mean? Does it refer to the call stack information from the rpb register?
If there is no debug information, the call stack can be obtained. Why does gdb still need DWARF2 unwind information?
At 2022-08-16 15:56:52, "Luis Machado" <luis.machado@arm.com> wrote:
>On 8/16/22 08:43, hilbert via Gdb wrote:
>> Hi ,
>> There are 4 ways to get the function call stack in the GDB Internals Manual. https://sourceware.org/gdb/papers/unwind.html
>> For x86_64, does GDB get information by parsing the .eh_frame section? Or just get the call stack by Parse the function prologues.
>>
>>
>>
>
>I'd say mostly 1 and 2. 1 is usually used with functions without debug information. 2 is used when there is debug information.
On 16/08/2022 10:19, hilbert via Gdb wrote:
> @Luis Machado
> Thank you very much .
> What does the sentence “functions without debug information”mean? Does it refer to the call stack information from the rpb register?
> If there is no debug information, the call stack can be obtained. Why does gdb still need DWARF2 unwind information?
When it says without debug information I believe that means without
DWARF info. This info is located either in .debug_xxx sections embedded
in the binary or, alternatively, supplied in a separate dwinfo/dwz file
that is tied to the binary (e.g. by search path and file name or by a
build id).
DWARF .debug_frame info can specify a lot more than how to do a stack
unwind. So, while the other methods enable this specific operation they
do not enable many other useful actions that gdb might need to establish
frame context and which DWARF info may enable. For full details see the
DWARF standard(s).
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
@Andrew Dinn Now I totally understand. Thank you very much for your patience. By the way, when a multithreaded program hits a breakpoint, GDB can use the command: thread ID to switch between threads arbitrarily, and view the memory and other information of each thread. This is also implemented using ptrace, right? At 2022-08-16 17:33:07, "Andrew Dinn" <adinn@redhat.com> wrote: >On 16/08/2022 10:19, hilbert via Gdb wrote: >When it says without debug information I believe that means without >DWARF info. This info is located either in .debug_xxx sections embedded >in the binary or, alternatively, supplied in a separate dwinfo/dwz file >that is tied to the binary (e.g. by search path and file name or by a >build id). > >DWARF .debug_frame info can specify a lot more than how to do a stack >unwind. So, while the other methods enable this specific operation they >do not enable many other useful actions that gdb might need to establish >frame context and which DWARF info may enable. For full details see the >DWARF standard(s). > >regards, > > >Andrew Dinn >----------- >Red Hat Distinguished Engineer >Red Hat UK Ltd >Registered in England and Wales under Company Registration No. 03798903 >Directors: Michael Cunningham, Michael ("Mike") O'Neill
On 16/08/2022 11:16, hilbert wrote: > @Andrew Dinn > Now I totally understand. Thank you very much for your patience. You are very welcome. > By the way, when a multithreaded program hits a breakpoint, GDB can use > the command: /*thread ID */ > /**/to switch between threads arbitrarily, and view the memory and > other information of each thread. > This is also implemented using ptrace, right? I would assume it relies on ptrace to stop all the threads. However, I have almost zero knowledge of how gdb actually controls the inferior process (my knowledge of gdb is exclusively on the gdb-process side of the fence). You will need to find someone else to obtain a definitive answer. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill
Got it .
Thank you very much.
At 2022-08-16 20:48:57, "Andrew Dinn" <adinn@redhat.com> wrote:
>On 16/08/2022 11:16, hilbert wrote:
>> @Andrew Dinn
>> Now I totally understand. Thank you very much for your patience.
>
>You are very welcome.
>
>> By the way, when a multithreaded program hits a breakpoint, GDB can use
>> the command: /*thread ID */
>> /**/to switch between threads arbitrarily, and view the memory and
>> other information of each thread.
>> This is also implemented using ptrace, right?
>I would assume it relies on ptrace to stop all the threads. However, I
>have almost zero knowledge of how gdb actually controls the inferior
>process (my knowledge of gdb is exclusively on the gdb-process side of
>the fence). You will need to find someone else to obtain a definitive
>answer.
>
>regards,
>
>
>Andrew Dinn
>-----------
>Red Hat Distinguished Engineer
>Red Hat UK Ltd
>Registered in England and Wales under Company Registration No. 03798903
>Directors: Michael Cunningham, Michael ("Mike") O'Neill
On 8/16/22 13:48, Andrew Dinn wrote: > On 16/08/2022 11:16, hilbert wrote: >> @Andrew Dinn >> Now I totally understand. Thank you very much for your patience. > > You are very welcome. > >> By the way, when a multithreaded program hits a breakpoint, GDB can use the command: /*thread ID */ >> /**/to switch between threads arbitrarily, and view the memory and other information of each thread. >> This is also implemented using ptrace, right? > I would assume it relies on ptrace to stop all the threads. However, I have almost zero knowledge of how gdb actually controls the inferior process (my knowledge of gdb is exclusively on the gdb-process side of the fence). You will need to find someone else to obtain a definitive answer. Sorry, for some funny reason (mailing list software/mail server) I'm not getting hilbert's replies. But Andrew provided great answers. Reading memory is usually done through /proc/<pid>/mem these days, as it is fastest. Reading registers for each thread is done by ptrace. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill >
>Sorry, for some funny reason (mailing list software/mail server) I'm not getting hilbert's replies. But Andrew provided great answers. >Reading memory is usually done through /proc/<pid>/mem these days, as it is fastest. > >Reading registers for each thread is done by ptrace. > > regards, > > Andrew Dinn I totally get it . This is very helpful for me. Thanks.
Luis Machado via Gdb <gdb@sourceware.org> writes:
> On 8/16/22 08:43, hilbert via Gdb wrote:
>> Hi ,
>> There are 4 ways to get the function call stack in the GDB Internals Manual. https://sourceware.org/gdb/papers/unwind.html
>> For x86_64, does GDB get information by parsing the .eh_frame section? Or just get the call stack by Parse the function prologues.
>>
>>
>>
>
> I'd say mostly 1 and 2. 1 is usually used with functions without debug
> information. 2 is used when there is debug information.
To expand on this a little, at least for version of GCC I'm using on
x86-64, the .eh_frame data replaces the .debug_frame data, so #2 and #3
are effectively merged.
The two "issues" raised against .eh_frame don't make sense to me. As
I understand it the .eh_frame encoding is roughly the same as the
.debug_frame encoding, so I don't think there's much space saving, and
GDB reads the .eh_frame information from the ELF, so the read-only
concern seems like a non-issue.
Thanks,
Andrew
For me, totally understand this.
It's unbelievable how knowledgeable you specialists are.
Thank you very much.
At 2022-08-18 22:05:16, "Andrew Burgess" <aburgess@redhat.com> wrote:
>Luis Machado via Gdb <gdb@sourceware.org> writes:
>
>> On 8/16/22 08:43, hilbert via Gdb wrote:
>>> Hi ,
>>> There are 4 ways to get the function call stack in the GDB Internals Manual. https://sourceware.org/gdb/papers/unwind.html
>>> For x86_64, does GDB get information by parsing the .eh_frame section? Or just get the call stack by Parse the function prologues.
>>>
>>>
>>>
>>
>> I'd say mostly 1 and 2. 1 is usually used with functions without debug
>> information. 2 is used when there is debug information.
>
>To expand on this a little, at least for version of GCC I'm using on
>x86-64, the .eh_frame data replaces the .debug_frame data, so #2 and #3
>are effectively merged.
>
>The two "issues" raised against .eh_frame don't make sense to me. As
>I understand it the .eh_frame encoding is roughly the same as the
>.debug_frame encoding, so I don't think there's much space saving, and
>GDB reads the .eh_frame information from the ELF, so the read-only
>concern seems like a non-issue.
>
>Thanks,
>Andrew