[Ltrace-devel] displaying arguments and build vs. host fiasco

Joe Damato ice799 at gmail.com
Sat Nov 6 03:19:43 UTC 2010


On Mon, Nov 1, 2010 at 2:09 PM, Petr Machata <pmachata at redhat.com> wrote:
> Hi list,
>
> I had a chance to look to the remaining ppc64/ppc32 test case failure in
> ltrace.  I believe this is a general problem, when you take exactly this
> example to x86_64/i386 it breaks, too.
>
> Here's the reproducer program, ww.c:
>
> struct ww { int a; int *pa; };
>
> #ifdef LIB
> int ble (void *x) { return 1; }
> #else
> int ble (void *x);
> #endif
>
> #ifndef LIB
> int main () {
>  struct ww x;
>  x.a = 3;
>  x.pa = &x.a;
>  return ble (&x);
> }
> #endif
>
> And corresponding config file, ww.conf:
> void ble(struct(int,int*)*)
>
> Use normal steps to compile ltrace in 64-bit mode, then compile the test
> case like this:
>
> $ gcc -DLIB -fpic -shared ~/ww.c -o libww.so
> $ gcc -ULIB ~/ww.c ./libww.so -o ww
> $ gcc -DLIB -fpic -shared -m32 ~/ww.c -o libww32.so
> $ gcc -ULIB -m32 ~/ww.c ./libww32.so -o ww32
>
> And run (output trimmed):
>
> # ./ltrace -F ~/ww.conf ./ww
> ble({ 3, 3 }) = <void>
>
> # ./ltrace -F ~/ww.conf ./ww32
> ble({ 3, -2311104 }) = <void>
>
> The value -2311104 is some random bit of the process address space, it might
> end up being "?" if the region it tries to read is inaccessible. The problem
> here is that 64-bit ltrace thinks the pointer alignment is 8 bytes, but it's
> tracing 32-bit inferior that thinks it should rather be 4.  In this
> particular case I can go to read_config_file.c and hard-code pointer
> alignment to 4 bytes, which fixes it.  At least on ppc, on x8664 this didn't
> work for me for some reason, it must be more or differently buggy.
>
> So,
> - front end needs to leave these sorts of decisions, like pointer alignment,
> to back end.  The simple trick with alignof won't work in general.

Agreed. We should be able to tell this from the ELF header, I believe.

> - front end needs to know it may need to precompute 32-bit layouts even on
> 64-bit.

I'm not sure I exactly follow what you mean here.

> - which means that i386 and x86_64 can no longer be totally separate
> backends, at least not the way they are now, or at least x86_64 has to
> include i386.  I'm thinking it shouldn't be terribly hard to merge them, ppc
> and s390 have always been like that AFAIK.

OK, I agree. I don't mind doing this work (unless some one else has
already started). Although, I am thinking that perhaps we should do
this in a separate branch and worry about merging this code in after
we do a long overdue release of ltrace.

I'm in favor of releasing a new version of ltrace as soon as possible
and I think that the changes listed above could be quite invasive. I
have no idea if the other architectures will be affected, so perhaps
for the release we are working toward, we can update the documentation
and let people know that ltrace and the binary being traced need to be
built for the same architecture.

List: what do you think?

joe



More information about the Ltrace-devel mailing list