This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Allow overloaded general functions
- From: "Matt Rice" <ratmice at gmail dot com>
- To: "Pierre Muller (gmail)" <pierre dot c dot muller at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 28 Mar 2008 20:25:22 -0700
- Subject: Re: [RFC] Allow overloaded general functions
- References: <firstname.lastname@example.org>
On Fri, Mar 28, 2008 at 9:22 AM, Pierre Muller (gmail)
> The address of 'ADD' is searched again using decode_line_1 function
> but there is later an assertion
> gdb_assert (sals.nelts == 1) in breakpoint.c at line 7366
> I could of course remove that assertion and check that in the list
> that I get, I do find the same source and line number I already had in
> my breakpoint structure, but what is the whole point of this?
> Why do we re_set breakpoints that are not pending?
> Is this for the unloading case ?
> If this is the case than the modification above is
> probably necessary.
> However, I am puzzled why other similar case don't have these
> troubles (like the decode_objc case.)
the reason this doesn't appear to be an issue with decode_objc is because
(gdb) break foo
 +[Bar foo] at main.m:30
 +[Foo foo] at main.m:19
therefore this line above the assertion
7310: s = b->addr_string;
will be unique and the assertion wont fail (i think),
though decode_objc currently also has its own problems that
i still need to revisit as per Daniels comments
> What should I do if I get a new additional 'ADD' function in the
> loaded library?
i can imagine a
might handle this but i'm not sure that that won't just open up a can
of worms :)
the RFA Keep breakpoints always inserted thread sounds like it could
help with this re_set ing (sorry its spread out across months in the
archives), i've been meaning to try those patches out.