* Inferior function call command set
@ 2003-05-01 20:55 Andrew Cagney
2003-05-01 21:12 ` Doug Evans
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2003-05-01 20:55 UTC (permalink / raw)
To: gdb
Hello,
GDB has a number of commands for controlling the behavior of inferior
function calls (developers think of them as call dummies). Looking in
"infcall.c" I find:
set/show coerce-float-to-double yes|no
set/show unwindonsignal yes|no
And I'm now looking to add a third:
set/show call-location on-stack|at-start|auto
So:
- anyone got a better name for this new command?
- should these be re-grouped into a set of sub commands vis:
set/show call coerce-float-to-double yes|no
set/show call unwind-on-signal yes|no
set/show call breakpoint-location on-stack|at-entry|auto
I'm figuring that "(gdb) set call" should provide a rough correspondance
to the existing "(gdb) call" command.
Comment away ...
Andrew
PS: Yes, this means that I've got a target using generic dummy frames
where the return breakpoint is on the stack.
PPS: While it doesn't currently work, it should be possible to make
on-stack function when the stack has no-execute set. It would lead to a
SIGSEG (instead of a SIGTRAP) which GDB should then map onto a breakpoint.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Inferior function call command set
2003-05-01 20:55 Inferior function call command set Andrew Cagney
@ 2003-05-01 21:12 ` Doug Evans
2003-05-01 21:28 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Doug Evans @ 2003-05-01 21:12 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
Andrew Cagney writes:
> GDB has a number of commands for controlling the behavior of inferior
> function calls (developers think of them as call dummies). Looking in
> "infcall.c" I find:
>
> set/show coerce-float-to-double yes|no
> set/show unwindonsignal yes|no
>
> And I'm now looking to add a third:
>
> set/show call-location on-stack|at-start|auto
Questions:
Out of curiousity, is there any need to have a runtime choice?
What happens if a value is set that the target doesn't support?
I presume this will be flagged as an error, right?
Is there any target that actually supports more than one?
(and that has all forms consistently working, rather than the
usual one working and the others bitrotting away ...)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Inferior function call command set
2003-05-01 21:12 ` Doug Evans
@ 2003-05-01 21:28 ` Andrew Cagney
2003-05-01 21:49 ` Doug Evans
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2003-05-01 21:28 UTC (permalink / raw)
To: Doug Evans; +Cc: gdb
> Andrew Cagney writes:
> > GDB has a number of commands for controlling the behavior of inferior
> > function calls (developers think of them as call dummies). Looking in
> > "infcall.c" I find:
> >
> > set/show coerce-float-to-double yes|no
> > set/show unwindonsignal yes|no
> >
> > And I'm now looking to add a third:
> >
> > set/show call-location on-stack|at-start|auto
>
> Questions:
>
> Out of curiousity, is there any need to have a runtime choice?
Entry point in ROM, non 1:1 code/stack, ...
> What happens if a value is set that the target doesn't support?
> I presume this will be flagged as an error, right?
>
> Is there any target that actually supports more than one?
> (and that has all forms consistently working, rather than the
> usual one working and the others bitrotting away ...)
An addition to the testsuite is implicit.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Inferior function call command set
2003-05-01 21:28 ` Andrew Cagney
@ 2003-05-01 21:49 ` Doug Evans
2003-05-01 22:48 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Doug Evans @ 2003-05-01 21:49 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
Andrew Cagney writes:
> > Out of curiousity, is there any need to have a runtime choice?
>
> Entry point in ROM, non 1:1 code/stack, ...
Apologies, still confused.
[having spent the last few days buried in the guts of
hand-called-function support such things are very much on my
mind these days]
How does having an entry point in ROM affect things?
It appears to me that all AT_ENTRY_POINT does is use the entry point
address as a magic number that will "never appear" in user code.
[thus if the callee is returning to it you know you're back in the "stub"]
In my port I added the ability for the user to override
CALL_DUMMY_ADDRESS since the entry point is ambiguous/unspecified.
[THAT would be a very welcome addition to the mainline code. :-)]
Pproviding both AT_ENTRY_POINT and ON_STACK is _far_ more effort than
providing the ability to override what gdb uses for CALL_DUMMY_ADDRESS.
Perhaps what I should have done is just hardwire it to 42. 1/2 :-).
No claim is made that there isn't a need for the runtime
stack/entry-point choice. But I still don't understand the need for it.
[Not that anyone has to spend time clearing up my understanding of course;
but if it's not that much effort, or if other people are also curious ...]
> An addition to the testsuite is implicit.
Ah.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Inferior function call command set
2003-05-01 21:49 ` Doug Evans
@ 2003-05-01 22:48 ` Andrew Cagney
2003-05-01 23:00 ` Doug Evans
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2003-05-01 22:48 UTC (permalink / raw)
To: Doug Evans; +Cc: gdb
> Andrew Cagney writes:
> > > Out of curiousity, is there any need to have a runtime choice?
> >
> > Entry point in ROM, non 1:1 code/stack, ...
>
> Apologies, still confused.
> [having spent the last few days buried in the guts of
> hand-called-function support such things are very much on my
> mind these days]
>
> How does having an entry point in ROM affect things?
> It appears to me that all AT_ENTRY_POINT does is use the entry point
> address as a magic number that will "never appear" in user code.
> [thus if the callee is returning to it you know you're back in the "stub"]
GDB tries to insert a breakpoint at that address (that doesn't work when
it is in a ROM :-) Looking at the MIPS, it turned out to also not work
very well when the entry point couldn't be found.
> In my port I added the ability for the user to override
> CALL_DUMMY_ADDRESS since the entry point is ambiguous/unspecified.
> [THAT would be a very welcome addition to the mainline code. :-)]
> Pproviding both AT_ENTRY_POINT and ON_STACK is _far_ more effort than
> providing the ability to override what gdb uses for CALL_DUMMY_ADDRESS.
> Perhaps what I should have done is just hardwire it to 42. 1/2 :-).
That isn't true.
For an up-to-date architecture, assuming the stack is executable(1),
there should be zero change. In fact, given problems with finding the
entry point address, on-stack is technically a better choice (although a
quick reality-check will stop that change dead). The d10v's tweak and
the retention of entry_point_address, stem from it being a true harvard
architecture.
A survey of architectures explicitly setting call_dummy_address reveals:
alpha: does something slightly weird (that may now be redundant)
avr: wrapped entry_point_address
m68hc11: wrapped entry_point_address
mips: wrapped entry_point_address, but with a hack for ROMs made
redundant by ``set call breakpoint-location on-stack''
sparc: depending on a compile time option, uses either
entry_point_address or the stack
so CALL_DUMMY_ADDRESS can/should probably be wired to entry_point_address.
> No claim is made that there isn't a need for the runtime
> stack/entry-point choice. But I still don't understand the need for it.
> [Not that anyone has to spend time clearing up my understanding of course;
> but if it's not that much effort, or if other people are also curious ...]
>
> > An addition to the testsuite is implicit.
Andrew
(1) Someone needs to get this working when the stack isn't executable.
The inferior would stop with a sigseg instead of sigtrap.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Inferior function call command set
2003-05-01 22:48 ` Andrew Cagney
@ 2003-05-01 23:00 ` Doug Evans
0 siblings, 0 replies; 6+ messages in thread
From: Doug Evans @ 2003-05-01 23:00 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
Andrew Cagney writes:
> GDB tries to insert a breakpoint at that address
Ah, yes. Forgot about that part. Thanks.
[In my target having a (pseudo-)arbitrary call-dummy-address
isn't a problem, so I kinda glossed over that part in my mind. Oh well.]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-05-01 23:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-01 20:55 Inferior function call command set Andrew Cagney
2003-05-01 21:12 ` Doug Evans
2003-05-01 21:28 ` Andrew Cagney
2003-05-01 21:49 ` Doug Evans
2003-05-01 22:48 ` Andrew Cagney
2003-05-01 23:00 ` Doug Evans
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).