From: Weimin Pan <weimin.pan@oracle.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 2/5] CTF: set up debug info for function arguments
Date: Mon, 1 Feb 2021 20:48:45 -0500 [thread overview]
Message-ID: <1612230528-25905-3-git-send-email-weimin.pan@oracle.com> (raw)
In-Reply-To: <1612230528-25905-2-git-send-email-weimin.pan@oracle.com>
Added this support in read_func_kind_type after gcc started generating
CTF for function arguments.
Expanded gdb.base/ctf-ptype.exp to test function arguments. Also fixed
some typos.
---
gdb/ctfread.c | 34 +++++++++++++++++++++++++++++++++-
gdb/testsuite/gdb.base/ctf-ptype.exp | 19 ++++++++++++++++---
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/gdb/ctfread.c b/gdb/ctfread.c
index 5a68d9c..c75fe25 100644
--- a/gdb/ctfread.c
+++ b/gdb/ctfread.c
@@ -652,8 +652,10 @@ struct ctf_tid_and_type
{
struct objfile *of = ccp->of;
ctf_dict_t *fp = ccp->fp;
- struct type *type, *rettype;
+ struct type *type, *rettype, *atype;
ctf_funcinfo_t cfi;
+ ctf_id_t *argv;
+ uint32_t argc;
type = alloc_type (of);
@@ -663,6 +665,36 @@ struct ctf_tid_and_type
TYPE_TARGET_TYPE (type) = rettype;
set_type_align (type, ctf_type_align (fp, tid));
+ /* Set up function's arguments. */
+ argc = cfi.ctc_argc;
+ type->set_num_fields (argc);
+ if (cfi.ctc_flags & CTF_FUNC_VARARG)
+ type->set_has_varargs (1);
+
+ if (argc != 0)
+ {
+ argv = XNEWVEC (ctf_id_t, argc);
+ if (ctf_func_type_args (fp, tid, argc, argv) == CTF_ERR)
+ {
+ xfree (argv);
+ return NULL;
+ }
+
+ type->set_fields
+ ((struct field *) TYPE_ZALLOC (type, argc * sizeof (struct field)));
+ struct type *void_type = objfile_type (of)->builtin_void;
+ /* If failed to find the argument type, fill it with void_type. */
+ for (int iparam = 0; iparam < argc; iparam++)
+ {
+ atype = get_tid_type (of, argv[iparam]);
+ if (atype)
+ type->field (iparam).set_type (atype);
+ else
+ type->field (iparam).set_type (void_type);
+ }
+ xfree (argv);
+ }
+
return set_tid_type (of, tid, type);
}
diff --git a/gdb/testsuite/gdb.base/ctf-ptype.exp b/gdb/testsuite/gdb.base/ctf-ptype.exp
index ffe40f1..056f712 100644
--- a/gdb/testsuite/gdb.base/ctf-ptype.exp
+++ b/gdb/testsuite/gdb.base/ctf-ptype.exp
@@ -63,10 +63,10 @@ gdb_test "ptype struct t_struct" "type = struct t_struct \{.*\[\r\n\] (unsign
# Test the equivalence between '.' and '->' for struct member references.
-if [gdb_test "ptype v_t_struct_p.v_float_member" "type = float"]<0 then {
+if [gdb_test "ptype v_struct1.v_float_member" "type = float"]<0 then {
return -1
}
-if [gdb_test "ptype v_t_struct_p->v_float_member" "type = float"]<0 then {
+if [gdb_test "ptype v_struct1->v_float_member" "type = float"]<0 then {
return -1
}
if [gdb_test "ptype v_t_struct_p.v_float_member" "type = float"]<0 then {
@@ -211,7 +211,7 @@ gdb_test "ptype the_highest" \
gdb_test "ptype the_highest.anonymous_level_1" \
"type = struct \{.*\[\r\n\] *int b;.*\[\r\n\] *struct \{.*\[\r\n\] *int c;.*\[\r\n\] *\} anonymous_level_2;.*\[\r\n\]}.*" \
- "ptype the_highest"
+ "ptype the_highest.anonymous_level_1"
# Print the type of the identifier ID, and check the response:
# - Expect to see PROTOTYPED as the type. PROTOTYPED is not a regular
@@ -255,8 +255,21 @@ proc ptype_maybe_prototyped { id prototyped plain { overprototyped "NO-MATCH" }
}
}
+ptype_maybe_prototyped "func_type" "int (*)(int (*)(int, float), float)" \
+ "int (*)()"
ptype_maybe_prototyped "old_fptr" "double (*)()" "double (*)()" \
"double (*)(void)"
+ptype_maybe_prototyped "new_fptr" "double (*)()" "double (*)()"
+ptype_maybe_prototyped "fptr" "int (*)(int, float)" "int (*)()"
+ptype_maybe_prototyped "fptr2" "int *(*)(int (*)(int, float), float)" \
+ "int *(*)()"
+ptype_maybe_prototyped "xptr" "int (*)(int (*)(), int (*)(), int)" \
+ "int (*)()" \
+ "int (*)(int (*)(void), int (*)(void), int)"
+ptype_maybe_prototyped "ffptr" "int (*(*)(char))(short int)" \
+ "int (*(*)())()"
+ptype_maybe_prototyped "fffptr" "int (*(*(*)(char))(short int))(long int)" \
+ "int (*(*(*)())())()"
# Test printing type of string constants and array constants, but
# requires a running process. These call malloc, and can take a long
--
1.8.3.1
next prev parent reply other threads:[~2021-02-02 1:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 1:48 [PATCH 0/5] CTF: bug fixes and new features Weimin Pan
2021-02-02 1:48 ` [PATCH 1/5] CTF: fix incorrect function return type Weimin Pan
2021-02-02 1:48 ` Weimin Pan [this message]
2021-02-02 1:48 ` [PATCH 3/5] CTF: handle forward reference type Weimin Pan
2021-02-02 1:48 ` [PATCH 4/5] CTF: add all members of an enum type to psymtab Weimin Pan
2021-02-02 1:48 ` [PATCH 5/5] CTF: multi-CU and archive support Weimin Pan
2021-02-05 15:42 ` [PATCH 3/5] CTF: handle forward reference type Tom Tromey
2021-02-05 19:33 ` Wei-min Pan
2021-02-05 15:40 ` [PATCH 2/5] CTF: set up debug info for function arguments Tom Tromey
2021-02-05 19:21 ` Wei-min Pan
2021-02-05 15:33 ` [PATCH 1/5] CTF: fix incorrect function return type Tom Tromey
2021-02-05 19:12 ` Wei-min Pan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1612230528-25905-3-git-send-email-weimin.pan@oracle.com \
--to=weimin.pan@oracle.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).