[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: a ptrace.h problem in debian-kfreebsd



Hi.

I'm a developer of a package in Debian, recently I'm told that my
package won't build on debian-kfreebsd anymore.

I would be usefull to name that package ;-)

According to BTS is seems be Bug#578457: scanmem: FTBFS on kfreebsd-*

   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.

Please install package freebsd-manpages and try
$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

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 question is how much packages really uses ptrace().
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.

Cheers

	Petr


Reply to: