305e13e67f
A relatively recent patch support for explicit locations, and part
of that patch cleaned up the way we parse breakpoint locations.
Unfortunatly, a small regression crept in for "*<EXPR>" breakpoint
locations. In particular, on PIE programs, one can see the issue by
doing the following, with any program:
(gdb) b *main
Breakpoint 1 at 0x51a: file hello.c, line 3.
(gdb) run
Starting program: /[...]/hello
Error in re-setting breakpoint 1: Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x51a
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x51a
Just for the record, this regression was introduced by:
commit
|
||
---|---|---|
.. | ||
lib/gdb | ||
py-arch.c | ||
py-auto-load.c | ||
py-block.c | ||
py-bpevent.c | ||
py-breakpoint.c | ||
py-cmd.c | ||
py-continueevent.c | ||
py-event.c | ||
py-event.h | ||
py-events.h | ||
py-evtregistry.c | ||
py-evts.c | ||
py-exitedevent.c | ||
py-finishbreakpoint.c | ||
py-frame.c | ||
py-framefilter.c | ||
py-function.c | ||
py-gdb-readline.c | ||
py-inferior.c | ||
py-infevents.c | ||
py-infthread.c | ||
py-lazy-string.c | ||
py-linetable.c | ||
py-newobjfileevent.c | ||
py-objfile.c | ||
py-param.c | ||
py-prettyprint.c | ||
py-progspace.c | ||
py-signalevent.c | ||
py-stopevent.c | ||
py-stopevent.h | ||
py-symbol.c | ||
py-symtab.c | ||
py-threadevent.c | ||
py-type.c | ||
py-unwind.c | ||
py-utils.c | ||
py-value.c | ||
py-varobj.c | ||
py-xmethods.c | ||
python-config.py | ||
python-internal.h | ||
python.c | ||
python.h |