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: Faster stepping amidst breakpoints


> Maxim Grigoriev actually noticed a regression, and I also noticed
> something on VxWorks.

The problem on VxWorks is more or less my own fault - I'm doing
something pretty shady: Inserting a breakpoint on VxWorks is done
via a WTX request which returns an "eventpoint ID".  To remove that
breakpoint, we use the associated routine with the eventpoint ID
of our breakpoint.  As a result, I need to keep a mapping between
breakpoint location and evenpoints IDs.  I was more or less using
the bp_location address as the key to my mapping (this is the shady
part), hoping that it would never be reallocated. Unfortunately, this
is not true at all, or at least not anymore: See breakpoint_re_set_one,
which calls update_breakpoint_locations... The approach seems to be:
unless all locations, recompute new locations, and then purge the old
locations (update_global_location_list).

The reason why this works with the current default is that the
breakpoints get removed before they are re-set, and so the map
gets emptied before the new locations are created.

I'm thinking of adding a target_private_data field in struct
bp_target_info. I think we can get away with memory management
by allocating the private data at breakpoint insertion, and
deallocating it at removal.  That way, I get rid of the map
entirely.

-- 
Joel


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