Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: catch load/unload not implemented on any target (remove?)
Date: Mon, 27 Oct 2008 00:41:00 -0000	[thread overview]
Message-ID: <20081027004044.GA3907@adacore.com> (raw)

Hello,

I was looking at converting the catch load/unload implementation
to using the bp_catchpoint kind. But looking at the implementation,
I realized there isn't any platform where this feature is implemented.
The documentation says HP/UX, but this isn't correct either, AFAICT.

The "protocol" between the breakpoint solib layers is based on
some macros being defined:

    SOLIB_LOADED_LIBRARY_PATHNAME(pid)
    LIB_UNLOADED_LIBRARY_PATHNAME(pid)
    SOLIB_CREATE_CATCH_LOAD_HOOK(pid,tempflag,filename,cond_string)
    SOLIB_CREATE_CATCH_UNLOAD_HOOK(pid, tempflag, filename, cond_string)

These macros used to be defined in the various target-dependent solib
files. For instance, in gdb-5.3, it was defined in: coff-solib.h,
pa64solib.h, solib.h, and somsolib.h.

I think that the mechanism of using macros is definitely OBE now, and
one should use "methods" in the target_so_ops structure.

I am conflicted as to what to do in the meantime: Leave the code as is,
and update the documentation that this feature is currently implemented
on no platform. Or remove the code entirely.

I am leaning towards removing the code entirely, for several reasons:
  - Documentating a feature as unimplemented seems silly;
  - I don't think there is much in the current code that once can
    reuse in order to implement this feature properly
  - When someone is ready to implement this feature again for his platform,
    there shouldn't be much to do in terms of infrastructure work to do at
    the breakpoint module level.  So it shouldn't be very difficult to
    implement. There might be one little difficulty based on the fact
    that some architectures will implement this feature using a phyical
    breakpoint (eg: svr4) whereas others won't (eg: Windows), but that
    shouldn't be very difficult to handle by using the right bp_kind.

Thoughts?

-- 
Joel


             reply	other threads:[~2008-10-27  0:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-27  0:41 Joel Brobecker [this message]
2008-10-27  4:16 ` Eli Zaretskii
2008-10-27 14:19 ` Aleksandar Ristovski
2008-10-27 13:57   ` Aleksandar Ristovski
2008-10-27 15:43 ` Daniel Jacobowitz
2008-10-27 17:45   ` Joel Brobecker

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=20081027004044.GA3907@adacore.com \
    --to=brobecker@adacore.com \
    --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