gmane.comp.debugging.ltrace.devel

Re: [PATCH 0/1] Attempt to fix libdl tracing whenattaching to PIDs

Petr Machata — 2013-03-23T01:16:43


The problem is that your libm has several IFUNC symbols that are called
internally.  This produces IRELATIVE relocations in .rela.plt.  Such
relocations don't have a symbol assigned, which is why ltrace shows
these as empty strings.  IRELATIVE relocations work like this:

  indirect(A + B)

I.e. take addend, add it to base (where the library was mapped), and the
result is an address of a function that, when called, returns the
address of the actual symbol.  So we need to do something similar: we
take addend, and look for a symbol with the same address.  If we find
it, then that's the name associated with this PLT slot.  Otherwise we
just make something up (currently there's ifunc< at >0xaddress).

The code for this is on pmachata/irelative.  It needs platform
cooperation: backends need to know about IRELATIVE relocations and check
for them.  Currently only x86_64 is known to work well.  I'll work
through backends that I have handy (ARM, PPC, IA64, s390) and
incrementally enable what works.

There are two test c

Re: [PATCH v3] ltrace: Add support for Imagination Technologies Meta

Markos Chandras — 2013-03-22T21:12:40

Thanks Petr.

Re: [PATCH v3] ltrace: Add support for ImaginationTechnologies Meta

Petr Machata — 2013-03-22T18:39:48


Pushed.

Thanks,
PM

Re: [PATCH v2] ltrace: Add support for Imagination Technologies Meta

Markos Chandras — 2013-03-22T12:25:20

No problem. I just sent v3 and I think I fixed all the problems you mentioned.

[PATCH v3] ltrace: Add support for ImaginationTechnologies Meta

Markos Chandras — 2013-03-22T12:24:09

From: Markos Chandras <markos.chandras< at >imgtec.com>

This patchset adds support for Imagination's Meta architecture.
The Meta Linux kernel port will be included in the Linux Kernel
v3.9. It also uses the generic system call numbers.

Signed-off-by: Markos Chandras <markos.chandras< at >imgtec.com>
---
 README                               |   1 +
 configure.ac                         |   1 +
 sysdeps/linux-gnu/metag/Makefile.am  |  16 ++
 sysdeps/linux-gnu/metag/arch.h       |  28 +++
 sysdeps/linux-gnu/metag/plt.c        |  38 ++++
 sysdeps/linux-gnu/metag/ptrace.h     |  21 ++
 sysdeps/linux-gnu/metag/regs.c       |  89 ++++++++
 sysdeps/linux-gnu/metag/signalent.h  |  53 +++++
 sysdeps/linux-gnu/metag/syscallent.h | 293 ++++++++++++++++++++++++
 sysdeps/linux-gnu/metag/trace.c      | 428 +++++++++++++++++++++++++++++++++++
 10 files changed, 968 insertions(+)
 create mode 100644 sysdeps/linux-gnu/metag/Makefile.am
 create mode 100644 sysdeps/linux-gnu/metag/arch.h
 create mode 100644 sysdeps/linux-gnu/metag/plt

Re: [PATCH v2] ltrace: Add support for ImaginationTechnologies Meta

Petr Machata — 2013-03-22T11:48:31


That's enough.  I'm sory, I didn't notice this.

Thanks,
PM

Re: [PATCH v2] ltrace: Add support for Imagination Technologies Meta

Markos Chandras — 2013-03-22T10:55:32

Which I just noticed it is wrong and should be replaced with
metag-*-linux-uclibc. I will fix that too

Re: [PATCH v2] ltrace: Add support for Imagination Technologies Meta

Markos Chandras — 2013-03-22T10:54:36

Hi Petr,

The patch already adds this in the README file:

metag-*-linux-gnu

So I am not sure what more information you want me to add there.

Re: [PATCH v2] ltrace: Add support for Imagination Technologies Meta

Markos Chandras — 2013-03-21T20:32:09

Hi,

Thanks. I will fix these issues an send a new patch again.
No I didn't run the testsuite. Just tested a lot of ELF files to make
sure it works as expected.
I will also update the README file as requested.

Thanks for the review.

Re: [PATCH v2] ltrace: Add support for ImaginationTechnologies Meta

Petr Machata — 2013-03-21T16:25:09


Please make those return arch_addr_t.


This should take arch_addr_t addr instead of void*.


This has wrong indentation.


This should be "switch (unit) {".


There should be a period and two spaces before the */.


The idiom commonly used in ltrace for handling this is assert(unit !=
unit); followed by an outright abort(); (for -DNDEBUG builds).  The
logic behind that is that either it's a hard error, and we should fail
early and loudly, or it's to be expected, and then instead of emitting
an error message, we shoud handle the situation gracefully.


Line too long, missing space after first comma, missing period at the
end of the sentence.

Is this a "can't happen" situation?  If yes, then see above.  Otherwise
keeping this at "not yet implemented" level is probably fine.


This line is too long, keep it below 80 characters please.  There are
several such problems.


Each English sentence in a string or a comment (unless it's a simple
explanatory tag, e.g. list of candidate instructions) should end with

Re: [PATCH 0/1] Attempt to fix libdl tracing whenattaching to PIDs

Petr Machata — 2013-03-21T11:29:30


In that case we are missing one PLT call in your output.  Tracing both
-x acos< at >libm\* and -e\* would help us indicate what the exact order of
operations is.

Would you mind sending me your libm.so binary privately?  Chances are
I'll be able co reproduce the problem with it, distill a test case, etc.

Thanks,
PM

Re: [PATCH 0/1] Attempt to fix libdl tracing when attaching to PIDs

Joe Damato — 2013-03-20T22:17:39

Right, I see. I misunderstood why/when -e should be used.


Ah, right of course.


Appears that my libm does go through the PLT for 2 things:

0000000000025ca0 <acos>:
[...]
   25cb6:       e9 f5 f7 fd ff          jmpq   54b0 <*ABS*+0x10590< at >plt>
[...]
   25cd7:       e9 64 fc fd ff          jmpq   5940 <*ABS*+0x1fc30< at >plt+0x3e0>


Nope, not an IFUNC.


Thanks for digging into this with me.

FWIW, I think the patch and test you wrote for fixing the dlsym/attach
bug look great and can be merged in whenever you feel it's ready.

Joe

Re: [PATCH 0/1] Attempt to fix libdl tracing whenattaching to PIDs

Petr Machata — 2013-03-20T01:25:44


This may be obvious, but note that -e really only matches PLT entries,
so you wouldn't see any actual calls from libm (unless they were really
done via PLT slots, like for malloc and free).


[...]


Suspicious.  This doesn't show up at my machine.  Valgrind is clean as
well.  we used to have a hack in ltrace that produced "anonymous" calls
like this, but that's been gone since before 0.7.

They shouldn't be the acos calls.  dlsym doesn't return a PLT slot
address, it returns the actual symbol, so the calls end up being direct.
I'm seeing the following:

$ ./a.out & ~/proj/ltrace/master/64/ltrace -p $(jobs -p) -e*
[1] 15103
my pid: 15103
libdl.so.2->__cxa_finalize(0x7fb12de47d78, 0, 0xffffffff, 0x7fb12de47d48)                        = 0x7fb12dc3f9d0
libm.so.6->__cxa_finalize(0x7fb12d8a9de0, 0, 0, 3)                                               = 0x7fb12dc3f9d0
+++ exited (status 0) +++

You have two calls from libm, I only have one.  The latter might me "my"
__cxa_finalize, but no clue what the former cou

Re: [PATCH 0/1] Attempt to fix libdl tracing when attaching to PIDs

Joe Damato — 2013-03-19T23:26:29


Ah yea, your implementation is much cleaner. Sorry, still finding my way
around the codebase again. Been a while.



There is something odd happening that I need to investigate a bit more.
I've noticed when trying to use ltrace to trace symbols loaded with dlsym,
only -x seems to actually work. I think this is because of where and how
plt_filter and static_filter are examined in the codebase. I tried to
re-arrange them and some surrounding code, but I ended up breaking existing
tests for -e.

That said, I am confused why this test case appears to pass when I run make
check.

I wrote a test program that dlopen's libm, and then uses dlsym to find
"acos" and calls the function after a short sleep so I can attach ltrace.

The test program looks like this:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <dlfcn.h>
#include <math.h>

int
main(void)
{
  void *handle = NULL;
  double (*acos)(double);

  printf("my pid: %d\n", getpid());

  handle = dlopen("/lib/x86_64-linux-gnu/libm.so.6", RTL

Re: [PATCH 0/1] Attempt to fix libdl tracing whenattaching to PIDs

Petr Machata — 2013-03-19T16:55:25


Oh, I think it was approximately the right thing.  We simply need to do
the same things on attach that we do after hitting _start.  I extracted
this to a separate function (process_hit_start), and call it from
open_pid and entry_breakpoint_on_hit.

Since there is no other way to get on dyn_addr in open_pid anyway, we
simply look for the main library, and read it there, like you did in
your patch.  That means we don't need to track that information at entry
breakpoint anymore, and we can get rid of struct entry_breakpoint.

A test case and this patch are sitting on pmachata/dlattach.  Tell me
what you think.

Thanks,
PM

---
 breakpoints.c |   38 +++++++++++---------------------------
 proc.c        |   21 ++++++++++++++++++++-
 proc.h        |    4 ++++
 3 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/breakpoints.c b/breakpoints.c
index 305bdae..a0c6b89 100644
--- a/breakpoints.c
+++ b/breakpoints.c
< at >< at > -343,45 +343,29 < at >< at > disable_all_breakpoints(struct process *proc)
   NULL, disable_bp_c

[PATCH v2] ltrace: Add support for ImaginationTechnologies Meta

Markos Chandras — 2013-03-19T11:40:29

From: Markos Chandras <markos.chandras< at >imgtec.com>

This patchset adds support for Imagination's Meta architecture.
The Meta Linux kernel port will be included in the Linux Kernel
v3.9. It also uses the generic system call numbers.

Signed-off-by: Markos Chandras <markos.chandras< at >imgtec.com>
---
 README                               |    1 +
 configure.ac                         |    1 +
 sysdeps/linux-gnu/metag/Makefile.am  |   16 ++
 sysdeps/linux-gnu/metag/arch.h       |   28 +++
 sysdeps/linux-gnu/metag/plt.c        |   38 +++
 sysdeps/linux-gnu/metag/ptrace.h     |   21 ++
 sysdeps/linux-gnu/metag/regs.c       |   89 ++++++++
 sysdeps/linux-gnu/metag/signalent.h  |   53 +++++
 sysdeps/linux-gnu/metag/syscallent.h |  293 ++++++++++++++++++++++++
 sysdeps/linux-gnu/metag/trace.c      |  415 ++++++++++++++++++++++++++++++++++
 10 files changed, 955 insertions(+), 0 deletions(-)
 create mode 100644 sysdeps/linux-gnu/metag/Makefile.am
 create mode 100644 sysdeps/linux-gnu/metag/arch.h
 create mode 100644 sys

[PATCH 1/1] Initialize libdl tracing when attachingltrace to specific PIDs

Joe Damato — 2013-03-18T04:53:37

---
 proc.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/proc.c b/proc.c
index aab0b62..d0de6f0 100644
--- a/proc.c
+++ b/proc.c
< at >< at > -561,6 +561,11 < at >< at > open_pid(pid_t pid)
 }
 
 struct process *leader = pid2proc(pid)->leader;
+struct library *pidlib = leader->libraries;
+while (pidlib->next != NULL)
+pidlib = pidlib->next;
+
+linkmap_init(leader, pidlib->dyn_addr);
 
 /* XXX Is there a way to figure out whether _start has
  * actually already been hit?  */

[PATCH 0/1] Attempt to fix libdl tracing whenattaching to PIDs

Joe Damato — 2013-03-18T04:53:36

Hi,

I noticed that ltrace was unable to trace symbols from runtime loaded dynamic objects when attaching to a PID. I've written a small (and ugly) patch to try to fix this. Let met know if there is a better way to do this and I'll be happy to make the change and submit a fix.

This was tested on my amd64 / ubuntu 12.04 machine.

Thanks,
Joe

Joe Damato (1):
  Initialize libdl tracing when attaching ltrace to specific PIDs

 proc.c |    5 +++++
 1 file changed, 5 insertions(+)

pmachata/config and pmachata/arm merged

Petr Machata — 2013-03-12T00:26:00

Hi there,

apparently ltrace 0.8 wasn't released at the end of February as I had
wished.  I would still like to make a release relatively soon, and as a
first step I merged two branches that I meant to merge for a long time
now.

- pmachata/config changes the way ltrace looks for config files.  Each
  library can now provide its own config file.  Every time a library is
  mapped in, ltrace looks whether a custom config file is provided.  We
  look for $SONAME.conf, or $BASENAME.conf, if SONAME is not available.
  If we find a file, we read it, and use the found prototypes to format
  calls in that library.

  I wrote about this back in December, see [2].

- pmachata/arm adds support for ARM machines.

The above two merges touch quite a bit of code (the overall diffstat is
about +4.8 -1.6KLOC), and most likely breaks some things, so please
test.  The ARM branch in particular messes with breakpoints, and I'm not
at all sure whether I haven't broken MIPS.

Thanks,
PM

[1] http://standards.freedesktop.org/basedi

Re: 3 patches for ltrace - fixes "armhf" target

Greg Alexander — 2013-03-06T20:00:51

Hi Petr -

Thanks!  That "get_next_pcs" idiom is exactly the direction I was heading
in, and it looks like you've done a much more thorough job than I would
have.

The pmachata/arm branch works perfectly for me, and even fixes a bug that
I had on my todo-list but had not characterized yet.  I'm squared away.
Sorry I do not know how to assist getting any of these changes into
Debian's release cycle...

- Greg

On Wed, Mar 06, 2013 at 07:48:26PM +0100, Petr Machata wrote:

Re: 3 patches for ltrace - fixes "armhf" target

Petr Machata — 2013-03-06T18:48:26


You might want to consider rebasing to 0.7.2 in Debian.  That is fairly
stable version in my opinion, which finally supports threads, fully
understands parameter passing convention, and allows tracing not only
the main binary, but libraries as well.  It doesn't however support ARM.
See below for that.


Great, glad to hear that.


Please take a look at the branch pmachata/arm.  We actually have a full
instruction decoding logic for software singlestepping now, ported from
GDB.

Your idea of trying PTRACE_SINGLESTEP first is appealing.  Some ARM
devices reportedly are capable of hardware singlestepping, but I don't
know if the Linux kernel supports that at all, and if yes, whether
there's a way to detect that you run on such hardware.  Unfortunately we
can't simply try PTRACE_SINGLESTEP, as older kernels did their own
emulation, which was unreliable, and we want to avoid using that.

Thanks,
PM