This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[RFC] Allow overloaded general functions
- From: "Pierre Muller \(gmail\)" <pierre dot c dot muller at gmail dot com>
- To: <gdb-patches at sourceware dot org>
- Date: Fri, 28 Mar 2008 17:22:03 +0100
- Subject: [RFC] Allow overloaded general functions
I tried to write a patch that allows to
set a breakpoint at each overloaded version of a procedure or function,
which is a fairly common feature in pascal language.
Below is a patch that allows, for pascal language
(but it could be used for all languages allowing several
version of the same function), to do :
(gdb) break ADD
[0] cancel
[1] all
[2] ADD at addstring.pp:16
[3] ADD at addlongint.pp:17
[4] ADD at addint.pp:17
> 1
Breakpoint 1 at 0x40102d: file addstring.pp, line 16.
Breakpoint 2 at 0x4010aa: file addlongint.pp, line 17.
Breakpoint 3 at 0x4010ca: file addint.pp, line 17.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
Thus this enables one to obtain the listing of the overloaded versions of
this function.
This seemed to be working fine, but
the problem is that this comes in conflict
with breakpoint_re_set function that is called
each time a new library is loaded.
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.)
What should I do if I get a new additional 'ADD' function in the
loaded library?
There also seems to be a conflict with the multiple breakpoint
that has been implemented recently for inlined functions.
Indeed if my three function are generated using the same
sources (with include files), then I get a weird result:
(gdb) b ADD
[0] cancel
[1] all
[2] ADD at add.inc:4
[3] ADD at add.inc:5
[4] ADD at add.inc:5
> 1
Breakpoint 1 at 0x40102d: file add.inc, line 4. (3 locations)
Note: breakpoint 1 also set at pc 0x4010aa.
Note: breakpoint 1 also set at pc 0x4010ca.
Breakpoint 2 at 0x401057: file add.inc, line 5. (3 locations)
Note: breakpoint 2 also set at pc 0x401057.
Note: breakpoints 1 and 2 also set at pc 0x4010aa.
Note: breakpoints 1 and 2 also set at pc 0x4010ca.
Breakpoint 3 at 0x401057: file add.inc, line 5. (3 locations)
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) inf b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE> 0x0040102d
1.1 y 0x0040102d in ADD at add.inc:4
1.2 y 0x004010aa in ADD at add.inc:4
1.3 y 0x004010ca in ADD at add.inc:4
2 breakpoint keep y <MULTIPLE> 0x00401057
2.1 y 0x00401057 in ADD at add.inc:5
2.2 y 0x004010aa in ADD at add.inc:5
2.3 y 0x004010ca in ADD at add.inc:5
3 breakpoint keep y <MULTIPLE> 0x00401057
3.1 y 0x00401057 in ADD at add.inc:5
3.2 y 0x004010aa in ADD at add.inc:5
3.3 y 0x004010ca in ADD at add.inc:5
Which is not what I would have liked.
This kind of multiple breakpoints
seems to be restricted to the same source-name/line number pair
being used several times, and thus is not
really extendable to the case of interest for me.
All comments most welcome.
Pierre Muller
Pascal language support maintainer for GDB
ChangeLog entry:
2008-03-28 Pierre Muller <muller@ics.u-strasbg.fr>
. linespec.c (decode_multiple_func): New function.
(decode_line_1): Call decode_multiple_func if
current_language is pascal.
Index: gdb/linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.74
diff -u -p -r1.74 linespec.c
--- gdb/linespec.c 1 Jan 2008 22:53:11 -0000 1.74
+++ gdb/linespec.c 28 Mar 2008 14:12:16 -0000
@@ -58,6 +58,13 @@ static struct symtabs_and_lines decode_o
char ***canonical,
char *saved_arg);
+static struct symtabs_and_lines decode_multiple_func (char **argptr,
+ int funfirstline,
+ struct symtab *file_symtab,
+ char ***canonical,
+ char *saved_arg);
+
+
static struct symtabs_and_lines decode_compound (char **argptr,
int funfirstline,
char ***canonical,
@@ -856,6 +863,16 @@ decode_line_1 (char **argptr, int funfir
/* Look up that token as a variable.
If file specified, use that file's per-file block to start with. */
+ if (current_language && current_language->la_language == language_pascal)
+ {
+ struct symtabs_and_lines values;
+ values = decode_multiple_func (©, funfirstline, file_symtab,
+ canonical, saved_arg);
+ if (values.sals != NULL)
+ return values;
+ }
+
+
return decode_variable (copy, funfirstline, canonical,
file_symtab, not_found_ptr);
}
@@ -1161,6 +1178,86 @@ decode_objc (char **argptr, int funfirst
return values;
}
+/* Search for multiple functions with same na
+ as allowed in pascal language for instance */
+
+
+struct symtabs_and_lines
+decode_multiple_func (char **argptr, int funfirstline,
+ struct symtab *file_symtab,
+ char ***canonical, char *saved_arg)
+{
+ struct symtabs_and_lines values;
+ struct symbol **sym_arr = NULL;
+ struct symbol *sym = NULL;
+ char *copy = NULL;
+ struct block *block = NULL;
+ unsigned i1 = 0;
+ unsigned i2 = 0;
+
+ struct symbol_search *symbols;
+ struct symbol_search *p;
+ struct cleanup *old_chain;
+ char *last_filename = NULL;
+ int first = 1;
+ values.sals = NULL;
+ values.nelts = 0;
+
+ /* must make sure that if we're interrupted, symbols gets freed */
+ if (file_symtab)
+ search_symbols (*argptr, FUNCTIONS_DOMAIN, 1,
+ (char **) &(file_symtab->filename), &symbols);
+ else
+ search_symbols (saved_arg, FUNCTIONS_DOMAIN, 0, (char **) NULL,
&symbols);
+
+ for (p = symbols; p != NULL; p = p->next)
+ {
+ i1++;
+ }
+
+ sym_arr = (struct symbol **) alloca ((i1 + 1) * sizeof (struct symbol
*));
+ sym_arr[i1] = NULL;
+ for (p = symbols; p != NULL; p = p->next)
+ {
+ if (p->symbol)
+ {
+ sym_arr[i2] = p->symbol;
+ i2++;
+ }
+ }
+
+ if (i2 > 1)
+ {
+ /* More than one match. The user must choose one or more. */
+ return decode_line_2 (sym_arr, i2, funfirstline, canonical);
+ }
+ else if (i2 == 1)
+ {
+ struct symbol *sym = symbols->symbol;
+
+ values.sals = (struct symtab_and_line *) xmalloc (
+ sizeof (struct symtab_and_line));
+ values.nelts = 1;
+ if (sym && SYMBOL_CLASS (sym) == LOC_BLOCK)
+ {
+ /* Canonicalize this, so it remains resolved for dylib loads. */
+ values.sals[0] = find_function_start_sal (sym, funfirstline);
+ build_canonical_line_spec (values.sals, SYMBOL_NATURAL_NAME (sym),
+ canonical);
+ }
+ else
+ {
+ /* The only match was a non-debuggable symbol. */
+ values.sals[0].symtab = NULL;
+ values.sals[0].line = 0;
+ values.sals[0].end = 0;
+ values.sals[0].pc = SYMBOL_VALUE_ADDRESS (sym_arr[0]);
+ }
+ }
+ return values;
+}
+
+
/* This handles C++ and Java compound data structures. P should point
at the first component separator, i.e. double-colon or period. As
an example, on entrance to this function we could have ARGPTR