[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