public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* How does GDB get the function call stack
@ 2022-08-16  7:43 hilbert
  2022-08-16  7:56 ` Luis Machado
  0 siblings, 1 reply; 11+ messages in thread
From: hilbert @ 2022-08-16  7:43 UTC (permalink / raw)
  To: gdb

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.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How does GDB get the function call stack
  2022-08-16  7:43 How does GDB get the function call stack hilbert
@ 2022-08-16  7:56 ` Luis Machado
  2022-08-16  9:19   ` hilbert
  2022-08-18 14:05   ` Andrew Burgess
  0 siblings, 2 replies; 11+ messages in thread
From: Luis Machado @ 2022-08-16  7:56 UTC (permalink / raw)
  To: hilbert, gdb

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re:Re: How does GDB get the function call stack
  2022-08-16  7:56 ` Luis Machado
@ 2022-08-16  9:19   ` hilbert
  2022-08-16  9:33     ` Andrew Dinn
  2022-08-18 14:05   ` Andrew Burgess
  1 sibling, 1 reply; 11+ messages in thread
From: hilbert @ 2022-08-16  9:19 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb

 @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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How does GDB get the function call stack
  2022-08-16  9:19   ` hilbert
@ 2022-08-16  9:33     ` Andrew Dinn
  2022-08-16 10:16       ` hilbert
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Dinn @ 2022-08-16  9:33 UTC (permalink / raw)
  To: hilbert, Luis Machado; +Cc: gdb

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re:Re: How does GDB get the function call stack
  2022-08-16  9:33     ` Andrew Dinn
@ 2022-08-16 10:16       ` hilbert
  2022-08-16 12:48         ` Andrew Dinn
  0 siblings, 1 reply; 11+ messages in thread
From: hilbert @ 2022-08-16 10:16 UTC (permalink / raw)
  To: Andrew Dinn; +Cc: Luis Machado, gdb

 @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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How does GDB get the function call stack
  2022-08-16 10:16       ` hilbert
@ 2022-08-16 12:48         ` Andrew Dinn
  2022-08-16 13:18           ` hilbert
  2022-08-16 13:27           ` Luis Machado
  0 siblings, 2 replies; 11+ messages in thread
From: Andrew Dinn @ 2022-08-16 12:48 UTC (permalink / raw)
  To: hilbert; +Cc: Luis Machado, gdb

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re:Re: How does GDB get the function call stack
  2022-08-16 12:48         ` Andrew Dinn
@ 2022-08-16 13:18           ` hilbert
  2022-08-16 13:27           ` Luis Machado
  1 sibling, 0 replies; 11+ messages in thread
From: hilbert @ 2022-08-16 13:18 UTC (permalink / raw)
  To: Andrew Dinn; +Cc: Luis Machado, gdb

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How does GDB get the function call stack
  2022-08-16 12:48         ` Andrew Dinn
  2022-08-16 13:18           ` hilbert
@ 2022-08-16 13:27           ` Luis Machado
  2022-08-16 13:46             ` hilbert
  1 sibling, 1 reply; 11+ messages in thread
From: Luis Machado @ 2022-08-16 13:27 UTC (permalink / raw)
  To: Andrew Dinn, hilbert; +Cc: gdb

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
> 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re:Re: How does GDB get the function call stack
  2022-08-16 13:27           ` Luis Machado
@ 2022-08-16 13:46             ` hilbert
  0 siblings, 0 replies; 11+ messages in thread
From: hilbert @ 2022-08-16 13:46 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb

>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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How does GDB get the function call stack
  2022-08-16  7:56 ` Luis Machado
  2022-08-16  9:19   ` hilbert
@ 2022-08-18 14:05   ` Andrew Burgess
  2022-08-19  1:57     ` hilbert
  1 sibling, 1 reply; 11+ messages in thread
From: Andrew Burgess @ 2022-08-18 14:05 UTC (permalink / raw)
  To: Luis Machado, hilbert, gdb

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re:Re: How does GDB get the function call stack
  2022-08-18 14:05   ` Andrew Burgess
@ 2022-08-19  1:57     ` hilbert
  0 siblings, 0 replies; 11+ messages in thread
From: hilbert @ 2022-08-19  1:57 UTC (permalink / raw)
  To: Andrew Burgess; +Cc: gdb

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-08-19  1:57 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-16  7:43 How does GDB get the function call stack hilbert
2022-08-16  7:56 ` Luis Machado
2022-08-16  9:19   ` hilbert
2022-08-16  9:33     ` Andrew Dinn
2022-08-16 10:16       ` hilbert
2022-08-16 12:48         ` Andrew Dinn
2022-08-16 13:18           ` hilbert
2022-08-16 13:27           ` Luis Machado
2022-08-16 13:46             ` hilbert
2022-08-18 14:05   ` Andrew Burgess
2022-08-19  1:57     ` hilbert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).