Calling an Ada subprogram with complex parameters

Calling an Ada subprogram with complex parameters

[jagorak]

Hi,

I'm trying to invoke from the GDB an Ada subprogram (say a procedure) which takes a
complex-type as a parameter. I'm struggling to work out how this can
be done.



Say I have a type

     type Rec is record
          a : Boolean;
          b : Integer;
     end record;

and a procedure, which takes a variable of this type as a parameter:

    procedure myProc( data : in Rec );

.
----
Now, from the GDB I'd like to make a call like this:
     (gdb) call myProc( data => Rec'(a => true, b => 55) );

but  this  doesn't  work  since GDB does not seem to fully support accessing
attributes (section 12.4.6.2 of the GDB manual). (means = aposthrophe
notation does not always work).



----
Therefore I wanted to try something else. For example:

          (gdb) call myProc($myRec);

where  $myRec  is  a  convenience  variable  of  type  "Rec", but this
wouldn't  work  either  since  convenience  variable  resides in
gdb-specific memory  space, complex types seem to be passed by reference and myProc
cannot access memory address of $myRec.

Besides,  even if that worked, here is another problem: I  was  able
to  'force' $myRec to be of type 'Rec' only by assigning   it   to
another   variable  of type Rec
          (e.g.  (gdb) set  $myRec  := otherVariableOfTypeRec)
which is not ideal since otherVariableOfTypeRec is not always
available. (In fact, in most cases it won't be.)
----

Another solution would be to have a specific memory address (since I
don't have any local variables available - the call to the procedure
is made almost without any context) set to a value of type Rec using type casting.
Which would be something like this:

      (gdb) p *0xABCDEF00 := something_here;
      (gdb) call myProc(Rec(*0xABCDEF00))

But the problem here is that the bytes occupied by "something_here"
have to be correctly set to what would variable of type Rec normally
occupy. Also "something_here" has to be a single expression. It cannot
be a record aggregate like for instance "(True, 55)" since obviously there is no
type associated with the 0xABCDEF00 memory address and GDB probably
doesn't know what to do with an aggregate notation. (BTW: Is there a
way to tell GDB to treat a memory address as if it was of a specific
type?)

When I try to run
     (gdb) call myProc(Rec(*0xABCDEF00))
just to see what happens... (*0xABCDEF00 set to whatever resides at
that address) I'm getting:
     Program received signal SIGILL, Illegal instruction.



I must mention here that I'm quite new to Ada so the solution to my
problem may be not by using a gdb feature, but by using and Ada
language feature... (e.g. appropriate casting).



Does anyone have any idea how I can solve this problem?



Many thanks,
Jan

Re: Calling an Ada subprogram with complex parameters

[jagorak]

I've    managed   to   work out how to make GDB treat an address as if
data there was of specific type and make a call accordingly.


(gdb) set ({Rec} 0xABCDEF00).a := false
(gdb) set ({Rec} 0xABCDEF00).b := 55
(gdb) call myProc({Rec} *0xABCDEF00))

Cheers
Jan

j> Hi,

j> I'm trying to invoke from the GDB an Ada subprogram (say a procedure) which takes a
j> complex-type as a parameter. I'm struggling to work out how this can
j> be done.



j> Say I have a type

j>      type Rec is record
j>           a : Boolean;
j>           b : Integer;
j>      end record;

j> and a procedure, which takes a variable of this type as a parameter:

j>     procedure myProc( data : in Rec );

j> .
j> ----
j> Now, from the GDB I'd like to make a call like this:
j>      (gdb) call myProc( data => Rec'(a => true, b => 55) );

j> but  this  doesn't  work  since GDB does not seem to fully support accessing
j> attributes (section 12.4.6.2 of the GDB manual). (means = aposthrophe
j> notation does not always work).



j> ----
j> Therefore I wanted to try something else. For example:

j>           (gdb) call myProc($myRec);

j> where  $myRec  is  a  convenience  variable  of  type  "Rec", but this
j> wouldn't  work  either  since  convenience  variable  resides in
j> gdb-specific memory  space, complex types seem to be passed by reference and myProc
j> cannot access memory address of $myRec.

j> Besides,  even if that worked, here is another problem: I  was  able
j> to  'force' $myRec to be of type 'Rec' only by assigning   it   to
j> another   variable  of type Rec
j>           (e.g.  (gdb) set  $myRec  := otherVariableOfTypeRec)
j> which is not ideal since otherVariableOfTypeRec is not always
j> available. (In fact, in most cases it won't be.)
j> ----

j> Another solution would be to have a specific memory address (since I
j> don't have any local variables available - the call to the procedure
j> is made almost without any context) set to a value of type Rec using type casting.
j> Which would be something like this:

j>       (gdb) p *0xABCDEF00 := something_here;
j>       (gdb) call myProc(Rec(*0xABCDEF00))

j> But the problem here is that the bytes occupied by "something_here"
j> have to be correctly set to what would variable of type Rec normally
j> occupy. Also "something_here" has to be a single expression. It cannot
j> be a record aggregate like for instance "(True, 55)" since obviously there is no
j> type associated with the 0xABCDEF00 memory address and GDB probably
j> doesn't know what to do with an aggregate notation. (BTW: Is there a
j> way to tell GDB to treat a memory address as if it was of a specific
j> type?)

j> When I try to run
j>      (gdb) call myProc(Rec(*0xABCDEF00))
j> just to see what happens... (*0xABCDEF00 set to whatever resides at
j> that address) I'm getting:
j>      Program received signal SIGILL, Illegal instruction.



j> I must mention here that I'm quite new to Ada so the solution to my
j> problem may be not by using a gdb feature, but by using and Ada
j> language feature... (e.g. appropriate casting).



j> Does anyone have any idea how I can solve this problem?



j> Many thanks,
j> Jan

Re: Calling an Ada subprogram with complex parameters

[Joel Brobecker]

> I've    managed   to   work out how to make GDB treat an address as if
> data there was of specific type and make a call accordingly.
> 
> 
> (gdb) set ({Rec} 0xABCDEF00).a := false
> (gdb) set ({Rec} 0xABCDEF00).b := 55
> (gdb) call myProc({Rec} *0xABCDEF00))

That's indeed what I would recommend. Just for the record, I verified
that the relevant info is in the GDB documentation.

-- 
Joel

Re[2]: Calling an Ada subprogram with complex parameters

[jagorak]

>> I've    managed   to   work out how to make GDB treat an address as if
>> data there was of specific type and make a call accordingly.
>> 
>> 
>> (gdb) set ({Rec} 0xABCDEF00).a := false
>> (gdb) set ({Rec} 0xABCDEF00).b := 55
>> (gdb) call myProc({Rec} *0xABCDEF00))

JB> That's indeed what I would recommend. Just for the record, I verified
JB> that the relevant info is in the GDB documentation.

Indeed it is in the manual - somehow I had missed that. Thanks.

Re: Calling an Ada subprogram with complex parameters

[Daniel Jacobowitz]

On Sat, Mar 17, 2007 at 11:11:24PM +0000, jagorak wrote:
> where  $myRec  is  a  convenience  variable  of  type  "Rec", but this
> wouldn't  work  either  since  convenience  variable  resides in
> gdb-specific memory  space, complex types seem to be passed by reference and myProc
> cannot access memory address of $myRec.

Actually, that's not true - convenience variables which have a
memory location are put into the target's memory.  Sometimes GDB
uses the stack, other times malloc is called under the hood.

> Does anyone have any idea how I can solve this problem?

Unfortunately not me - maybe Joel will have some helpful advice.  I
know less Ada than you do, I'm sure :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re[2]: Calling an Ada subprogram with complex parameters

[jagorak]

>> where  $myRec  is  a  convenience  variable of type "Rec", but this
>> wouldn't   work   either  since  convenience  variable  resides  in
>> gdb-specific  memory  space,  complex  types  seem  to be passed by
>> reference and myProc cannot access memory address of $myRec.

DJ> Actually, that's not true - convenience variables which have a
DJ> memory location are put into the target's memory.  Sometimes GDB
DJ> uses the stack, other times malloc is called under the hood.

That  is  very  good  news to me, as using absolute addressess is much
less convenient than using convenience variables.

HOWEVER,  GDB is complaining when I try to use convenience variable in
a  subprogram  call,  whereas  it is not complaining when I give it an
absolute  address.  (This  is why I thought convenience variables were
not stored in target memory).

Let me explain.

Assuming Rec is a type as defined in my previous posts, using absolute
address  I can set data & make a call as follows (this is actually the
solution to my problem I described in my original post).

   (gdb) set ({Rec} 0xABCDEF00).a := false
   (gdb) set ({Rec} 0xABCDEF00).b := 55
   (gdb) call myProc({Rec} *0xABCDEF00))

ABOVE WORKS FINE.

Now,  when  I use a convenience variable (still using absolute address
but only  as  'read-only-trick' to get the convenience variable to be set to
the appropriate type), GDB is complaining.

Here is the process:
     // The 'read-only-trick'  to  set $conVar to appropriate type (I'm
     // not bothered with the value of $conVar at that stage)
     // Address can be random and doesn't really matter here.
     (gdb) set $conVar := ({Rec} 0xABCDEF00)

     // set $conVar to what I want
     (gdb) set $conVar.a := false
     (gdb) set $conVar.b := 55

     // ---> NOW - here is the problem: <----
     (gdb) call myProc($conVar)
     gdb says: Attempt to take address of value not located in memory.

I tried to work out what is the address of $conVar, as I would do with
'normal' variable, but it doesn't work:
     (gdb) p &$conVar
     gdb says: Attempt to take address of non-lval

Which  is curious - previously I was able to set the value of $conVar,
but now it is complaining $conVar is not a non-lval.

It seems that as if gdb treats each instance of a convenience variable
in a command as the actual value which the variable holds.

I  think  I  need  to  have  a  better  understanding  of  convenience
variables.  I'm  not even sure whether I understand correctly what gdb
says  to  me - your help is greatly appreciated! (coudn't work this out
with the help of the gdb manual)

Many, many thanks,
Jan

Re: Calling an Ada subprogram with complex parameters

[Daniel Jacobowitz]

On Mon, Mar 19, 2007 at 08:08:02PM +0000, jagorak wrote:
> >> where  $myRec  is  a  convenience  variable of type "Rec", but this
> >> wouldn't   work   either  since  convenience  variable  resides  in
> >> gdb-specific  memory  space,  complex  types  seem  to be passed by
> >> reference and myProc cannot access memory address of $myRec.
> 
> DJ> Actually, that's not true - convenience variables which have a
> DJ> memory location are put into the target's memory.  Sometimes GDB
> DJ> uses the stack, other times malloc is called under the hood.
> 
> That  is  very  good  news to me, as using absolute addressess is much
> less convenient than using convenience variables.

It depends on what you've done with them.  As you see below, it's
possible in some cases to have a convenience variable of a compound
type.  If you do that, it does not have a memory location.

GDB would need support for pushing the variable into target memory at
the appropriate time (and deciding what "appropriate" meant).

This is made rather tricky, because (A) calling malloc perturbs the
program, so we want to do it as little as possible, but (B) putting a
variable on the stack breaks if the called function saves its address.

-- 
Daniel Jacobowitz
CodeSourcery

Re[2]: Calling an Ada subprogram with complex parameters

[jagorak]

DJ> type. If you do that, it does not have a memory location.

DJ> GDB would need support for pushing the variable into target memory at
DJ> the appropriate time (and deciding what "appropriate" meant).

    That explains the messages I was seeing.
    That  means  I'll  have  to  stick  to  using absolute addresses for
    compound types.

    Many thanks for your support!

    Cheers
    Jan