This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 3/3] bpstat_what removal [rediff]


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Pedro> Do you think it would be hard to split this into smaller pieces?

Jan> Yes, I will do - just later.  IMO we should probably more talk
Jan> about its goal than about specifics of the implementation.

Yeah.  I read this thread and I had some trouble following it.
I hope this note doesn't further confuse things.

Pedro> - It should be possible to fix PR 9436 without

Jan> We can pretend PR 9436 does not exist.

One thing I would like to understand better is the long-term design.
It seems to me that right now we have a few problems.  I would like to
understand (1) whether and how your patch fixes them, and (2) what our
(by which I guess I mostly mean Pedro's :-) ideal design would look
like.

My understanding of the problems:

* We don't nicely handle multiple breakpoints at one location.
  (AFAIK not touched by your change.)

* bpstat_what is difficult to understand & modify, particularly the table.
  (You fixed this.)  

* It is too hard to add new kinds of breakpoints.  See ifunc or
  next-over-throw.
  (Maybe partially fixed?)

For multiple breakpoints ... to me it seems like we want to have some
way to notify *all* the breakpoints at a given spot, with some kind of
decision making coming later about how to proceed.

A case that has come up a couple times is having a way for Python to add
new invisible breakpoints, with Python code attached.

E.g., suppose you wanted to track malloc+free.  You would want to put
breakpoints on these that don't interfere with stepping, but you would
also want to make sure that the Python handler is run every time the
breakpoint is hit -- even if the user also does "break malloc".

So here you'd like some sorting: have the internal breakpoint actions
trigger first, collect their responses ("continue the current
operation") and then the user breakpoints.

I suppose we'd have to look at a lot more cases to see if there is some
sensible generic approach.

Pedro> To recap, IMO, the current problem with bpstat_main_action is
Pedro> that a few of its values aren't really independent and mutually
Pedro> exclusive with the others -- BPSTAT_WHAT_CHECK_SHLIBS and
Pedro> BPSTAT_WHAT_CHECK_JIT.

Jan> What if a new breakpoint type wants to stop?  What if a new
Jan> breakpoint type does not want to stop?  And how they combine if
Jan> they happend together with other events?  While there exists answer
Jan> for it I do not know offhand.  I know offhand with my
Jan> implementation.  I should post a patch introducing new breakpoint
Jan> types in both variants of the bpstat_what implementation.

Are you saying that the bpstat_main_action actually encodes several
things which should actually be independent?  I think that is consistent
with what I see in your patch, I just wanted to be sure.

Pedro> - I feel that even getting rid of the table bpstat_what_main_action
Pedro> table

Jan> Yes, it has to be done.

Yes.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]