This is the mail archive of the 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: [RFC] Allow overloaded general functions

On Fri, Mar 28, 2008 at 9:22 AM, Pierre Muller (gmail)
<> wrote:


>  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
[0] cancel
[1] all
[2] +[Bar foo] at main.m:30
[3] +[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
[2] pending

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.

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