Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot
Date: Fri, 01 Jun 2012 16:21:00 -0000	[thread overview]
Message-ID: <4FC8EC08.1060609@redhat.com> (raw)
In-Reply-To: <1338562868-22411-1-git-send-email-Joakim.Tjernlund@transmode.se>

On 06/01/2012 04:01 PM, Joakim Tjernlund wrote:

> 
> gdb mistakenly inserts a special shared library BP even though
> there area no such libs in either linux or u-boot.
> Fix by testing for ld.so presence.


Thanks.  I've ran it through the testsuite just in case; no regressions.

Anyone know of any reason we shouldn't put this in?  I don't know the
history of these particular fallbacks, and don't know which hosts or
conditions might need them.  I've found this as further back as
around gdb-4.9 (1993), where we had:

/* On SVR4 systems, for the initial implementation, use some runtime startup
   symbol as the "startup mapping complete" breakpoint address.  The models
   for SunOS and SVR4 dynamic linking debugger support are different in that
   SunOS hits one breakpoint when all mapping is complete while using the SVR4
   debugger support takes two breakpoint hits for each file mapped, and
   there is no way to know when the "last" one is hit.  Both these
   mechanisms should be tied to a "breakpoint service routine" that
   gets automatically executed whenever one of the breakpoints indicating
   a change in mapping is hit.  This is a future enhancement.  (FIXME) */

#define BKPT_AT_SYMBOL 1

#if defined (BKPT_AT_SYMBOL) && defined (SVR4_SHARED_LIBS)
static char *bkpt_names[] = {
#ifdef SOLIB_BKPT_NAME
  SOLIB_BKPT_NAME,              /* Prefer configured name if it exists. */
#endif
  "_start",
  "main",
  NULL
};
#endif

and at that point solib.c was a mess used by both SVR4 and a.out SunOS.

(Incidentally, the present solib-sunos.c is only really used on a.out BSD
targets, not by Solaris.)

I've written a ChangeLog entry for you.  Please see the gdb/CONTRIBUTE
for the next time.  Thanks.

2012-06-01  Joakim Tjernlund  <Joakim.Tjernlund@transmode.se>

	* solib-svr4.c (enable_break): Don't fallback to setting the solib
	event breakpoint at _start, __start or main if a program
	interpreter is not found.
---

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index bd0141a..307e483 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty)
 	}
     }

-  if (!current_inferior ()->attach_flag)
+  if (interp_name != NULL && !current_inferior ()->attach_flag)
     {
       for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
 	{


  reply	other threads:[~2012-06-01 16:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-01 15:01 [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs: .. (gdb) tar remote bdi:2001 Remote debugging using bdi:2001 0xeff80050 in ?? () (gdb) mon reset (gdb) cont Continuing. Warning: Cannot insert breakpoint -1. Error accessing memory address 0xc0000000: Unknown error 4294967295 Joakim Tjernlund
2012-06-01 16:21 ` Pedro Alves [this message]
2012-06-01 18:05   ` [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot Jan Kratochvil
2012-06-01 17:37     ` Pedro Alves
2012-06-01 18:05       ` Jan Kratochvil
2012-06-01 18:19         ` Pedro Alves
2012-06-01 19:08           ` Jan Kratochvil
2012-06-01 20:25         ` Mark Kettenis
2012-06-07  0:00       ` Maciej W. Rozycki
2012-06-08 12:10         ` Pedro Alves
2012-06-08 12:39           ` Jan Kratochvil
2012-06-08 13:07             ` Pedro Alves
2012-06-08 13:37               ` Mark Kettenis
2012-06-08 13:45                 ` Pedro Alves
2012-06-08 15:45           ` Maciej W. Rozycki
2012-06-01 18:07     ` Jan Kratochvil
2012-06-05 15:45   ` Pedro Alves

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=4FC8EC08.1060609@redhat.com \
    --to=palves@redhat.com \
    --cc=Joakim.Tjernlund@transmode.se \
    --cc=gdb-patches@sourceware.org \
    /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