From: Eli Zaretskii <eliz@gnu.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: Debugging through exec() (Linux MAY_FOLLOW_EXEC)
Date: Fri, 18 Aug 2006 12:27:00 -0000 [thread overview]
Message-ID: <usljui5z3.fsf@gnu.org> (raw)
In-Reply-To: <20060815142819.GA26405@host0.dyn.jankratochvil.net> (message from Jan Kratochvil on Tue, 15 Aug 2006 16:28:19 +0200)
> Date: Tue, 15 Aug 2006 16:28:19 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb@sourceware.org
>
> Currently gdb does not notice `exec' at all - it does not apply the inferior
> changes to its debugging information about the inferior. By default in the
> point of `exec' it will lose any breakpoints and the execution will continue
> without any gdb influence and the program will just finish uncaught.
>
> If you turn on "catch exec" you will get back the control after `exec' changes
> the virtual memory context but gdb will still expect the original executable is
> still loaded. All the sources will be displayed for the original program and
> breakpoints put to the addresses according to the debuginfo of the original
> program, still everything will be messed up as a complately different
> executable is already running.
Thanks for the explanations, but I seem to be dense today, because I
don't get to the cheese yet.
Perhaps if you could describe a scenario where the current behavior is
inconvenient, and what does your patch change in this respect, I will
understand the issues.
Please also tell how, if at all, the suggested changes interact with
follow-fork mode.
next prev parent reply other threads:[~2006-08-18 12:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060614142552.GA15021@nevyn.them.org>
[not found] ` <20060615203519.GA9603@host0.dyn.jankratochvil.net>
[not found] ` <20060721181556.GA9150@lace.redhat.com>
[not found] ` <20060721184421.GA22820@nevyn.them.org>
[not found] ` <20060722123102.GA1936@lace.redhat.com>
[not found] ` <20060724190332.GA13612@nevyn.them.org>
[not found] ` <20060729185317.GA16200@host0.dyn.jankratochvil.net>
[not found] ` <200607312038.k6VKchKj018729@elgar.sibelius.xs4all.nl>
[not found] ` <20060805164144.GA23819@host0.dyn.jankratochvil.net>
[not found] ` <20060808160113.GC21032@nevyn.them.org>
2006-08-14 15:07 ` Jan Kratochvil
2006-08-14 21:20 ` Eli Zaretskii
2006-08-14 21:39 ` Daniel Jacobowitz
2006-08-15 3:22 ` Eli Zaretskii
2006-08-15 14:28 ` Jan Kratochvil
2006-08-18 12:27 ` Eli Zaretskii [this message]
2006-09-04 17:59 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=usljui5z3.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox