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