I don't know if this is an appropriate fix but I have found that if gdb
is run in batch mode by gforth with -batch-silent instead of just with
the -q quiet switch then gdb will exit even when the old ptrace
capabilities are not re-enabled. With -batch-silent and ptrace
restricted (https://www.kernel.org/doc/Documentation/security/Yama.txt),
gforth will display the reason returned from gdb:
see +
Code +
0x55eca76d: /tmp/gforthdis.oWWqwv4yAj:4: Error in sourced command
file:
Cannot access memory at address 0x55eca76d
end-code
ok
With ptrace_scope set to 0, the output appears to be as expected:
see +
Code +
0x000055ebda5b176d <gforth_engine+5805>: mov
%r13,0x22538c(%rip) # 0x55ebda7d6b00 <saved_ip>
0x000055ebda5b1774 <gforth_engine+5812>: lea 0x8(%r14),%rax
0x000055ebda5b1778 <gforth_engine+5816>: mov (%rax),%rax
0x000055ebda5b177b <gforth_engine+5819>: mov %rax,-0x9e8(%rbp)
0x000055ebda5b1782 <gforth_engine+5826>: mov (%r14),%rax
0x000055ebda5b1785 <gforth_engine+5829>: mov %rax,-0x9e0(%rbp)
0x000055ebda5b178c <gforth_engine+5836>: add $0x8,%r14
0x000055ebda5b1790 <gforth_engine+5840>: mov -0x9e8(%rbp),%rdx
0x000055ebda5b1797 <gforth_engine+5847>: mov -0x9e0(%rbp),%rax
0x000055ebda5b179e <gforth_engine+5854>: add %rdx,%rax
0x000055ebda5b17a1 <gforth_engine+5857>: mov %rax,-0x9d8(%rbp)
0x000055ebda5b17a8 <gforth_engine+5864>: add $0x8,%r13
0x000055ebda5b17ac <gforth_engine+5868>: mov -0x9d8(%rbp),%rax
0x000055ebda5b17b3 <gforth_engine+5875>: mov %rax,(%r14)
0x000055ebda5b17b6 <gforth_engine+5878>: mov %rax,%r15
0x000055ebda5b17b9 <gforth_engine+5881>: mov -0x8(%r13),%rbx
0x000055ebda5b17bd <gforth_engine+5885>: mov %rbx,%rax
0x000055ebda5b17c0 <gforth_engine+5888>: jmpq 0x55ebda5b016d
<gforth_engine+173>
end-code
Might the use of batch mode for gdb be appropriate?
Here is a patch for 0.7.3:
--- gforth-0.7.3+dfsg.orig/dis-gdb.fs
+++ gforth-0.7.3+dfsg/dis-gdb.fs
@@ -48,7 +48,7 @@ defer gdb-addr-sep-char ( -- c )
addr 0 <<# gdb-addr-sep-char hold # #s 'x hold # #>
append-extend-string #>>
addr u + 0 <<# # #s 'x hold # #> append-extend-string #>>
r> base ! cr
- s\" \nset logging off\nquit\n\" >$file2 && gdb -nx -q -p `ps -p $$
-o ppid=` -x $file2 2>/dev/null >/dev/null && rm $file2 && grep -v \"of
assembler\" $file && rm $file" append-extend-string
+ s\" \nset logging off\nquit\n\" >$file2 && gdb -nx -batch-silent -p
`ps -p $$ -o ppid=` -x $file2 2>/dev/null >/dev/null && rm $file2 &&
grep -v \"of assembler\" $file && rm $file" append-extend-string
2dup (system) 2swap drop free throw throw if
addr u dump
endif ;
On Thu, 12 Jan 2012 18:15:50 +0100 Anton Ertl
<an...@mips.complang.tuwien.ac.at> wrote:
> On Thu, Jan 12, 2012 at 09:12:39AM +0100, Ph. Marek wrote:
> > Package: gforth
> > Version: 0.7.0+ds1-6
> > Severity: normal
> >
> > Using gforth=0.7.0+ds1-6 and gdb=7.4-1~cvs20111117.2 the "see" word
doesn't
> > work for built-ins, like "+". GDB just hangs, I expect it gets a
bad command.
>
> I have seen that yesterday on an AMD64 Ubuntu 11.10 system. The
> reason there was that it is now possible to restrict the ptrace call
> such that attaching gdb to a non-child process is no longer possible
> (in Gforth, gdb tries to attach to its grandparent process). gdb produces
> an error message (that goes to /dev/null) and waits for your input.
>
> You can work around that by re-enabling the old ptrace capabilities.
> Currently the box is down, so I cannot check how I did it, but a
> little googling brought up that
>
> echo 0 >/proc/sys/kernel/yama/ptrace_scope
>
> might help.
>
> If this restriction continues to be the default on a significant
> number of systems, I guess that the long-term solution is to call the
> library that gdb uses for disassembling directly instead of through
> gdb.
>
> - anton
>
>
>
