[Ltrace-devel] [PATCH] Fix ppc64 ABI support

Anderson Lizardo anderson.lizardo at gmail.com
Fri Feb 15 16:28:10 UTC 2008


On Fri, Feb 15, 2008 at 10:41 AM, Luis Machado
<luisgpm at linux.vnet.ibm.com> wrote:
>  Checking the source i see that we had some functions that needed to be
>  platform specific being called in common code (namely umovelong and
>  umovestr). These two functions call PTRACE directly and thus need some
>  special attention since things could vary between architectures.
>
>  This patch moves those two functions to the arch-specific files
>  contained inside "sysdeps/linux-gnu/" and adds a new "type" parameter
>  that is valuable during the recovering of data through PTRACE.

This surely duplicates a lot of code, given that for other
architectures the code is the same. Maybe it is a better idea to have
generic umovelong and umovestr functions and add arch-specific
arch_umovelong and arch_umovestr ones. Then in arch.h for the the
ppc64 you could have:

#define ARCH_HAVE_UMOVELONG 1
#define ARCH_HAVE_UMOVESTR 1

The would enable compilation of the arch-specific functions.

See arch_enable_breakpoint() and arch_disable_breakpoint() for the
other architectures to have an idea of how it works. Of course, the
new  type argument would still be necessary.

Here are some comments regarding ppc/trace.c (note that I don't know
the details of the PPC architecture):

- the code in gimme_arg*() functions seems to assume that when arg_num
== 0, we are entering a function. This is bad, IMHO, as code changes
in other parts may break this assumption. Why note keep a stack of
called functions like in i386?
- you are using global variables for keeping track which registers map
to which arguments (if I understand the code correctly). How would
that work when tracing multiple processes at the same time?

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia
Manaus - Brazil



More information about the Ltrace-devel mailing list