Re: a ptrace.h problem in debian-kfreebsd
Thank you very much for your information
Do you mean that I should replace PTRACE_* with PT_* for kfreebsd or for both kfreebsd and linux?
And I'll try to port it
On Mon, May 3, 2010 at 5:49 PM, Petr Salinger <Petr.Salinger@seznam.cz>
I would be usefull to name that package ;-)
I'm a developer of a package in Debian, recently I'm told that my
package won't build on debian-kfreebsd anymore.
According to BTS is seems be Bug#578457: scanmem: FTBFS on kfreebsd-*
Please install package freebsd-manpages and try
Then I tried, even a previous version won't build. And the problem is
about the ptrace.h file. PTRACE_PEEKDATA was not defined there.
So in linux, these macro are named PTRACE_PEEKDATA, PTRACE_POKEDATA and
etc, and in FreeBSD, those are called PT_READ_D and etc. In debian-kfreebsd,
you'll see "PTRACE_PEEKDATA" in `man ptrace`, but in the header file
'sys/ptrace.h', you can see only PT_READ_D there.
$man -k ptrace
ptrace (2) - process trace
ptrace (2freebsd) - process tracing and debugging
tcptraceroute (1) - A traceroute implementation using TCP packets
tcptraceroute.mt (1) - A traceroute implementation using TCP packets
$ man 2freebsd ptrace
The question is how much packages really uses ptrace().
In my ubuntu machine, I
found that PT_READ_D-like names are still there, where PTRACE_PEEKDATA-like
names are defined as alias there.
I wonder which one should debian-kfreebsd follow, but I believe an set
of alias will be needed, otherwise everybody will need a dirty hack for it.
The gdb of course, but it works on plain FreeBSD, so it knows differences
between linux kernel and freebsd kernel.
The ptrace() on linux and FreeBSD have slightly different interface:
long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data);
int ptrace(int request, pid_t pid, caddr_t addr, int data);
Especially int/long difference leads into hidden troubles on kfreebsd-amd64, so there are no longer previous aliases.
It is much better to fail early during compile-time,
not later at runtime.
You might consider to either drop binaries for both GNU/kFreeBSD architectures or port to FreeBSD interface, i.e. use one PT_IO
instead of loops of PTRACE_PEEKDATA/PTRACE_POKEDATA
and use PT_ATTACH/PT_DETACH instead of PTRACE_ATTACH/PTRACE_DETACH.