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

[Petr Machata]

06.11.2010 04:19, Joe Damato wrote:
>> 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.

If yes, then I don't know how.

>
>> - 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.

Currently the layout of structures is computed at the time of reading 
the config file, and is computed for the architecture of ltrace, not the 
inferior.  What I had in mind with this remark is that it needs to know 
that ltrace on 64-bit machine may also support 32-bit inferiors, and 
that it should do this double computation.

>> - 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.

FWIW I have a patch that implements this here:
https://github.com/pmachata/ltrace/commits/pmachata

x86 is still a stand-alone back end, but x86_64 now dispatches all its 
32-bit request to it.  Which really was the goal, to reduce the duplicity.

As for alignments and sizeofs, that uses proc->mask_32bit to decide 
which alignment set to use.  This particular choice may be less then 
ideal, as I realized later, because the back end can define up to three 
supported machines (look for LT_ELF_MACHINE macros).  But we never hit 
this constraint in back ends that we have.

For computing alignof and sizeof, a new back end hook was added, 
arch_arg_type_alignof/sizeof (and corresponding macro 
ARCH_HAVE_ARG_TYPE_ALIGNOF/SIZEOF).  That hook can simply return -1 to 
request the default value to be picked.  I imagine this might make 
defining architectural exceptions simpler.  The default hook is then 
almost the same as it was before, except it now makes some assumptions 
about how mask_32bit changes the layout, so it works on x86_64 and i386 
out of the box.  I haven't yet had a chance to test it on ppcs.  I hope 
to today.  I may end up removing those mask_32bit heuristics if they 
turn out to make no sense in general.

With those patches it _almost_ passes 32-on-64 testsuite on x86_64.  The 
remaining problem is with arguments on the stack, which seem to get 
overwritten during a nested library call (that problem is there even on 
pure x86).  I haven't had a chance to properly investigate this yet.

> 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?

Yeah, actually that's what I was thinking when writing that code.  Let's 
release what we have.  I can then get rid of my ltrace project on github 
(which is around just so that I can easily request pushes into 
ice799/ltrace) and continue the development on proper branch in upstream 
repository.

PM