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
_______________________________________________
Ltrace-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/ltrace-devel
