From: Nat! <nat@mulle-kybernetik.com>
To: gdb@sourceware.org
Subject: How to add a second "this" (sort of, or maybe do something totally different)
Date: Fri, 25 Feb 2022 01:28:35 +0100 [thread overview]
Message-ID: <d403f219-8a21-5031-a4fe-f44f8249f63a@mulle-kybernetik.com> (raw)
Hi
my problem is this:
I have lots of functions (actually compiled Objective-C methods), that
look very similiar:
void *foo1( id self, unsigned int _cmd, struct { int a; void * b;}
*_param);
void *foo2( id self, unsigned int _cmd, struct { double a; void *
b;} *_param);
void *foo3( id self, unsigned int _cmd, struct { int a; int b; int
c; } *_param);
and so on. The first two parameters are always the same.
The actual method parameters are accessed indirectly through "_param".
So the functions may have looked like this in the Objective-C source code:
int foo1:(int) a :(void *) b;
void foo2:(double) a :(void *) b;
char *foo3:(int) a :(int) b :(int) c;
As the programmer passes "a", "b" and not "_param", it would be nice to
get the debugger to print "_param->a", if the user enters "p a". gdb can
already do this expansion for "this" or "self". As it's Objective-C, the
"this" for the debugger is taken and it's "self". The user doesn't have
to type "p self->_ivar" but can use "p _ivar" to access instance
variables. That's nice, but doesn't extend to "_param".
I am looking for the least effort route to support something like this
for "_param" as well, in gdb. What would be really great, would be to
also show the struct fields in the stack trace instead of "_param".
Ciao
Nat!
P.S.
Getting the compiler to output some fake dwarf "DW_TAG_formal_parameter"
for each struct field with a computed dwarf expression, is maybe the
proper way it could be done. But that's not least effort for me by a
long shot.
next reply other threads:[~2022-02-25 0:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 0:28 Nat! [this message]
2022-03-08 22:00 ` Tom Tromey
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=d403f219-8a21-5031-a4fe-f44f8249f63a@mulle-kybernetik.com \
--to=nat@mulle-kybernetik.com \
--cc=gdb@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).