public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: GDB 7.4 adds shlib_events BPs, casuing problem in debugging vmlinux
Date: Thu, 31 May 2012 00:31:00 -0000	[thread overview]
Message-ID: <OF020DF8F0.F8677382-ONC1257A0F.00028D6D-C1257A0F.0002DD4C@transmode.se> (raw)
In-Reply-To: <20120530213539.GA32534@host2.jankratochvil.net>


Jan Kratochvil <jan.kratochvil@redhat.com> wrote on 2012/05/30 23:35:39:
>
> On Wed, 30 May 2012 16:25:29 +0200, Joakim Tjernlund wrote:
> > Found this in solib-svr4.c which I think is the problem:
> > static const char * const bkpt_names[] =
> > {
> >   "_start",
> >   "__start",
> >   "main",
> >   NULL
> > };
> > ...
> > ...
> >  if (!current_inferior ()->attach_flag)
> >     {
> >       for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
> >    {
> >      msymbol = lookup_minimal_symbol (*bkpt_namep, NULL, symfile_objfile);
> >      if ((msymbol != NULL) && (SYMBOL_VALUE_ADDRESS (msymbol) != 0))
> >        {
> >          sym_addr = SYMBOL_VALUE_ADDRESS (msymbol);
> >          sym_addr = gdbarch_convert_from_func_ptr_addr (target_gdbarch,
> >                           sym_addr,
> >                           &current_target);
> >          create_solib_event_breakpoint (target_gdbarch, sym_addr);
> >          return 1;
> >        }
> >    }
> >     }
> >
> > This will insert the above BP just because the symbol  _start is present. Seems like
> > there are missing safe guards to avoid the unwanted BP
>
> This breakpoint is wanted.  If GDB fails to insert the "_r_debug_state"
> breakpoint into ld.so for whatever reason then after initial DT_NEEDED loading
> of shared libraries ld.so gives away control to the main executable.
> "_start" is the possible symbol there how to catch just exit from ld.so.

BTW, if this is all about ld.so, then why not guard this with
if (interp_name) /* Check if there is a ld.so at all */
{
...
}

  parent reply	other threads:[~2012-05-31  0:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF9A4BFC71.726F89BA-ONC1257A0E.004B4830-C1257A0E.004BCCB4@LocalDomain>
2012-05-30 14:26 ` Joakim Tjernlund
2012-05-30 21:36   ` Jan Kratochvil
2012-05-30 22:36     ` Joakim Tjernlund
2012-05-31  0:31     ` Joakim Tjernlund [this message]
2012-06-01 14:48       ` Jan Kratochvil
     [not found]     ` <OF4E766EE5.67CABBE6-ONC1257A0E.007AF1CF-C1257A0E.007C2C7F@LocalDomain>
2012-05-31 13:26       ` Joakim Tjernlund
2012-05-30 13:49 Joakim Tjernlund

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=OF020DF8F0.F8677382-ONC1257A0F.00028D6D-C1257A0F.0002DD4C@transmode.se \
    --to=joakim.tjernlund@transmode.se \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).