public inbox for
 help / color / mirror / Atom feed
From: Nat! <>
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: <> (raw)


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;}  
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".



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.

             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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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).