From: Nobuyoshi Nakada <nobu@...>
Date: 2011-09-15T15:27:57+09:00
Subject: [ruby-core:39563] Re: [Ruby 1.9 - Bug #5193] ruby_thread_data_type linker errors fixed with RUBY_EXTERN

Hi,

At Wed, 14 Sep 2011 10:36:09 +0900,
Motohiro KOSAKI wrote in [ruby-core:39536]:
> Symbol exposing doesn't have any regression risk. So, it can
> be commited into 193 if nobu agreed. But, I strongly hope to
> add explicitly disclaimer comments. We may stop export
> rb_method_entry() when debugger issue has been resoleved more
> cleaner way. I don't recommend other gems use it.

rb_method_entry() doesn't seem necessary for me.  The uses of
it are:

* extracting cfuncs from defined methods, ObjectSpace._id2ref
  and Thread#alive?, and
* checking the current method is bound at RUBY_EVENT_C_RETURN.

The reason for _id2ref is that threads are stored in debug
contexts as object IDs, and reversed when accessing with
checking if it's alive at same time.  I have no idea why such
roundabout way is used, and guess this could be simpler.

For the latter use, I suspect rb_method_boundp() would be
better than rb_method_entry().

> Nobu, what do you think?

Current state is https://github.com/nobu/ruby-debug/commit/4453c34537

There are still rb_vm_make_env_object() and
rb_vm_get_sourceline().  Seems the only workaround is to export
these functions.


diff --git a/vm.c b/vm.c
index 6e2e9a4..18cc81d 100644
--- a/vm.c
+++ b/vm.c
@@ -50,6 +50,15 @@ void vm_analysis_operand(int insn, int n, VALUE op);
 void vm_analysis_register(int reg, int isset);
 void vm_analysis_insn(int insn);

+/*
+ * TODO: replace with better interface at the next patch release.
+ *
+ * these functions are exported just as a workaround for ruby-debug
+ * for the time being.
+ */
+RUBY_FUNC_EXPORTED VALUE rb_vm_make_env_object(rb_thread_t *th,
rb_control_frame_t *cfp);
+RUBY_FUNC_EXPORTED int rb_vm_get_sourceline(const rb_control_frame_t *cfp);
+
 void
 rb_vm_change_state(void)
 {


-- 
Nobu Nakada