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] Fix internal error on breaking at a multi-locations caller


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

Jan> patch deals with break after `up' into the caller where the caller line has
Jan> multiple locations (instances).  Discussion is contained in the code.
Jan> Original bugreport at: https://bugzilla.redhat.com/show_bug.cgi?id=488572

Thanks.

Jan> +      /* Find all the other PCs for a line of code with multiple instances
Jan> +	 (locations).  If the instruction is in the middle of an instruction
Jan> +	 block for source line GDB cannot safely find the same instruction in
Jan> +	 the other compiled instances of the same source line because the other
Jan> +	 instances may have been compiled completely differently.

[...]

Jan> +	 The current implementation will place the breakpoint at the expected
Jan> +	 returning address of the current instance of the caller.  But the
Jan> +	 other instances will get the breakpoint at the first instruction of
Jan> +	 the source line - therefore before the call would be made.  Another
Jan> +	 possibility would be to place the breakpoint in the other instances at
Jan> +	 the start of the next source line.

Based on the documentation of `break', and also my mental model of
debugging with gdb, I think that the best behavior here would be to
simply set a single breakpoint here -- the one corresponding to the
instance that is currently being executed.  Then we don't have to
worry about the other instances, and we won't set odd breakpoints
elsewhere.

What do you (or anybody) think of that?

Tom


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