Re: eliminate deprecated_insert_raw_breakpoint. what's left.

[Peter Schauer <peterschauer at gmx dot net>]

> 
> > > This is AIX code.  Looks like this can easily be converted to a
> > > momentary breakpoint?
> > 
> > I am actually wondering whether this is still needed. It could!
> > So, the first thing I wanted to do was to run the testsuite without.
> > I'm currently building GDB, which is taking forever, and will then
> > run AdaCore's testsuite.
> 
> Looking at the code, it should be executed each time the SP register
> gets changed, which means it should trigger when calling functions
> from GDB. Deactivating exec_one_dummy_insn entirely did not result
> in any regression I could notice. That was on AIX 7.1.
> 
> That being said, I'm hesitant of removing the code regardless,
> since this could only be needed in specific situations which might
> not be covered by the testsuites we have.
> 
> I was looking at how to replace that call, but I am not sure
> how to fix the code up, though. Perhaps we could just write
> the breakpoint instruction in by hand, rather than go through
> the breakpoint module? After all, it is already doing almost
> everything else by hand!
> 
> In fact, looking at the code again now, I'm a little more tempted
> to see what happens if we remove it ;-).

I hope to be able to shed some light on this problem, although it
is more than fifteen years ago that I did some work for GDB on AIX.

>From my notes back then, AIX 3 and AIX 4 had a very peculiar ptrace
implementation, where the current ptrace state of the inferior process
(including the current process registers) was maintained approximately
512 bytes below the current user stack pointer of the process.

This resulted in problems with AIX inferior function calls.
If the called function takes one or more large aggregate parameters
by value, or if you pass a large amount of parameters, the ptrace
area gets corrupted, when the dummy function call parameters are
pushed on the user stack, due to this awkward AIX stack layout.

To work around this problem, the execution of a dummy instruction
(when altering the stack pointer) caused the kernel to move the ptrace
state area further below on the user stack, allowing GDB to write below
the current user stack safely.
In GDB 6.x, rs6000_push_dummy_call even secured the stack partially during
pushing of the arguments, via an additional call of
regcache_raw_write_signed to gdbarch_sp_regnum (gdbarch), which is
no longer present in current versions of GDB.

Executing the dummy instruction is very fragile, especially if signals
get involved during the execution, and it didn't even help, if more
than ~100 bytes of parameters were pushed on the user stack on AIX 4.
Back then, there was no other choice though.

Unfortunately I do not know, if this peculiar AIX stack layout is still
used in AIX 5 or later, maybe Ulrich Weigand could tell you more about it.

I think you could/should zap exec_one_dummy_insn, provided that you test
a dummy function call on the oldest AIX version that GDB has to support,
with a large aggregate parameter, which is passed by value.

-- 
Peter Schauer			Peter.Schauer@mytum.de