Hi,
I'm working with Zach's github tree. There, configure requires
libelf.pc to be installed.
I don't think that's correct, there's at least one other libelf
available in elfutils, which has incompatible versioning and doesn't
ship the .pc file. It's available on Red Hat-line of linuxes:
Hi,
No canadian crosses this time around, this should be easily reproducible
on any old linux box.
Let's have the following code in zz.c
#ifdef LIB
void work (char *x) { *x = 'x'; }
void call (char *x, char* y, void (*cb) (char *)) {
cb (y);
*x = (*y)++;
}
#else
void work (char *x);
void
01.11.2010 19:32, Joe Damato wrote:
On Mon, Nov 1, 2010 at 7:58 AM, Petr Machatapmach...@redhat.com wrote:
01.11.2010 14:58, Marc Kleine-Budde wrote:
Sounds like a plan.
Wouldn't something simpler do? I wonder about the AC_CHECK_LIBRARY magic
that you have in there, is that necessary?
09.11.2010 01:08, Joe Damato wrote:
On Wed, Nov 3, 2010 at 11:00 AM, Petr Machatapmach...@redhat.com wrote:
02.11.2010 17:49, Petr Machata wrote:
The problem
here is that the register set is preserved in struct Process, not in
struct callstack_element, and so is overwritten when nested call
Hi,
as agreed on some time ago, I took current 0.6.0 from Joe Damato's github
repository and pushed it to Alioth. That should be the default place for
upstream development from now on.
While packaging ltrace for Fedora, I found that a test suite (that I
optimistically re-enabled :) ) fails
Hi list,
The cleaned-up branch with thread-tracing code is
pmachata/threads-revised-revised (the repository doesn't allow history
rewrite, which I'll address in another mail). That branch is compilable
and the test suite passes in every commit, and besides the commits are
organized topically as
Petr Machata pmach...@redhat.com writes:
I wrote a small patch that implements support for SDT probes to ltrace.
SDT probes are used by some applications. This is how it looks when
used on a test binary of mine (edited to fit):
It's on pmachata/stapsdt. Comments welcome.
FWIW, I added
Steve Fink sph...@gmail.com writes:
On Sat, Aug 6, 2011 at 6:58 PM, Petr Machata pmach...@redhat.com wrote:
Hi there,
SDT probes are used by some application--typically, they are placed to
strategic places, such as when MySQL parses a query, or when OpenJDK
compiles a method. I believe
Andreas Schwab sch...@linux-m68k.org writes:
The parameter save area starts at sp+8 on ppc32 and at sp+112 on
ppc64.
Thanks, I pushed the patch to master.
PM
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
Adam Dingle a...@yorba.org writes:
ltrace is an extremely useful tool!
I find that when I'm tracing a tree of child processes using the -f
option, the following type of output (which is printed unconditionally)
becomes distracting:
[pid 6494] --- Called exec() ---
[pid 6496] --- Called
Michael K. Edwards m.k.edwa...@gmail.com writes:
I expect that the first attached patch will fix the PPC32 build. (I
have made the offending bits of code conditional on SIZEOF_LONG == 8
rather than on __powerpc64__, since this is really a matter of
ptrace() being defined to return a long.)
Steve Fink sph...@gmail.com writes:
On Mon, Aug 8, 2011 at 3:54 AM, Petr Machata pmach...@redhat.com wrote:
Steve Fink sph...@gmail.com writes:
On Sat, Aug 6, 2011 at 6:58 PM, Petr Machata pmach...@redhat.com wrote:
Hi there,
SDT probes are used by some application--typically
Hi there,
Regarding this:
During detaching the process that ltrace attached to previously, the
process is occasionally SIGSEGVed or SIGTRAPed. I don't understand
why that is happening, but it turns out it's not a regression at all.
Both current master and an ancient and heavily patched
Imre Deak imre.d...@gmail.com writes:
tracing some programs in Ubuntu Oneiric/x86_64 like totem or firefox
gives no library call trace. I got the same result with the ltrace version
from git:
For firefox, the case might be that there is a wrapper script in effect.
Ltrace could be able to
Hi there,
I wrote about my pmachata/threads branch several times over the past
half a year or so. I spent about the last two or three months fixing
all sorts of races, regressions and odd cases, most of them found by my
colleague Michal Nowak, who was in charge of testing the feature for
Honggyu Kim hong...@aces.snu.ac.kr writes:
I'm currently trying to use ltrace on my ARM board.
I found that ltrace works on many Linux systems running on ARM as well
from README doc.
However, Itrace seems not to be running on my ARM board.
The problem is that it often generates Segmentation
Hi there,
there's a couple deficiencies in ltrace that could be tagged as ABI
problems. On the branch pmachata/abi, I'm working towards fixing them.
The areas where ltrace is lacking are following:
- we assume that all interesting data fit into long. That's not true on
32-bit machines, where
Petr Machata pmach...@redhat.com writes:
there doesn't seem to be any way to reliably compute addresses of
stubs. There are symbols for stubs in symbol table, but that goes
away when stripped [...] We might still use them if they are in
symbol table [...]
This is implemented on pmachata
Sedat Dilek sedat.di...@googlemail.com writes:
there seems to be a ltrace-0.6.0 release [1], but I looked for an
official tarball at [2] and did not found it.
On the Wild Wild Web I found some tarballs from Fedora and openSUSE
project, but I don't know on which (git-revision) they are based
Hi there,
I added a new configury flag, HAVE_LIBSELINUX. I also added a new back
end hook, trace_fail_warning(pid_t), which is called when we fail to
PTRACE_ATTACH or PTRACE_TRACEME. If we HAVE_LIBSELINUX, this hook
checks value of deny_ptrace SELinux boolean and if it finds it turned
on, it
Petr Machata pmach...@redhat.com writes:
Sedat Dilek sedat.di...@googlemail.com writes:
there seems to be a ltrace-0.6.0 release [1], but I looked for an
official tarball at [2] and did not found it.
On the Wild Wild Web I found some tarballs from Fedora and openSUSE
project, but I don't
Hi list,
I'm wrapping up the pmachata/libs branch that I forked in February.
The changes that this should bring are:
* tracing of calls made from DSOs
* interface clarifications
* full support of PPC
The latter was rolled into the former as I needed to validate my code on
something else than
Florian Echtler f...@butterbrot.org writes:
[...]
read(37, D, 1) = 1
write(26, W, 1)= 1
write(38, f, 1)= 1
read(25, W, 16)= 1
read(37, D, 1)
Florian Echtler f...@butterbrot.org writes:
On 25.04.2012 11:39, Petr Machata wrote:
If you forked off 0.6.0, the threading fixes aren't in yet. Might that
be the cause? I don't see any evidence of threads in your snippet, but
if the process that you are tracing shares the address space
Florian Echtler f...@butterbrot.org writes:
On 25.04.2012 14:58, Petr Machata wrote:
But in fact clone support was in for a long time now, maybe try to pass
-f on the command line. The tracing might still fail, calls and returns
might get missed across threads, but chances are it will work
Petr Machata pmach...@redhat.com writes:
Florian Echtler f...@butterbrot.org writes:
I forgot to mention one peculiar aspect: I explicitly have to add the
system functions I'm interested in via -x func, otherwise, they will
not be traced. I assume that is due to the way the Android linker
Florian Echtler f...@butterbrot.org writes:
On the pro side: no spurious crashes anymore. I'm assuming this was
indeed a multi-threading issue.
However, on the con side: no library calls are traced anymore either.
(Syscalls still work fine). As before, my command line is:
If you see no
Juan,
this is the third attempt that I'm making at contacting you regarding
ltrace project that you administer on Alioth. I'm sorry for spamming
your work addresses (which I don't even know if work), but my other
attempts have been fruitless so far.
I would like to provide tarballs for (over a
Andrey Zonov z...@freebsd.org writes:
On 8/27/12 1:30 PM, Petr Machata wrote:
Andrey Zonov z...@freebsd.org writes:
I'm now porting ltrace on FreeBSD
One more nit. I don't like that the directory is called FreeBSD. Why
not call it freebsd? That's what the triplet name is.
Thank you
Sedat Dilek sedat.di...@gmail.com writes:
On Thu, Aug 30, 2012 at 2:21 PM, Petr Machata pmach...@redhat.com wrote:
the branch pmachata/revamp was now merged to master.
What's the status of MIPS?
What's missing for it?
What GIT branch or tag are you recommending for MIPS?
I don't know
Andreas Schwab sch...@linux-m68k.org writes:
sysdeps/linux-gnu/m68k/plt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Applied.
Thank you,
PM
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
Hi there,
this is fourth attempt at contacting you over the past half a year or
so. I'm therefore sending this to any and all addresses that I could
gather, that I think might belong to you.
You are the only person who has the administration rights to ltrace
project, and it's not helpful that
Sedat Dilek sedat.di...@gmail.com writes:
My experiments were done on a Ubuntu/precise AMD64 host.
The MIPSEL toolchain consists of binutils-2.22, gcc-4.6.3 and
uClibc-0.9.32.1 and was provided as a so-called download-toolchain
provided by the Freetz project.
So a quick walk-trough my patch
Sedat Dilek sedat.di...@gmail.com writes:
On Sat, Sep 1, 2012 at 2:15 AM, Petr Machata pmach...@redhat.com wrote:
Sedat Dilek sedat.di...@gmail.com writes:
[ handle_event.c ]
Fix pred uninitialized in pending_new_remove().
That should go into a separate patch. It's a good catch
Sedat Dilek sedat.di...@gmail.com writes:
as promised here my first impressions on ltrace v0.7.0-git on my
MIPSEL router.
Thank you for this. I'm trying to install Debian Wheezy on emulated
MIPS64el as I write this, but it takes ages to finish.
I have built ltrace statically against
Sedat Dilek sedat.di...@gmail.com writes:
On Mon, Sep 3, 2012 at 12:29 PM, Petr Machata pmach...@redhat.com wrote:
Sedat Dilek sedat.di...@gmail.com writes:
Interesting. The include changes that I did in that commit must have
resolved the compilation error that you were seeing.
Inclusion
Sedat Dilek sedat.di...@gmail.com writes:
root@fritz:/var/tmp# ./ltrace --config=ltrace.conf --debug=71 ./a.out
21 | tee ltrace-debug-71.txt
- Sedat -
P.S.: ltrace-debug-71.txt (XZ-compressed) file attached!
This looks like setup of _start breakpoint:
DEBUG: plt.c:41: plt_addr 410830 ndx
Paul Buerger pbuer...@avetec.org writes:
diff --git a/ltrace-d57c9f8/handle_event.c b/ltrace_fix/handle_event.c
index 1720cb3..384e868 100644
--- a/ltrace-d57c9f8/handle_event.c
+++ b/ltrace_fix/handle_event.c
@@ -522,7 +522,7 @@ calc_time_spent(Process *proc) {
if (tv.tv_usec =
Sedat Dilek sedat.di...@gmail.com writes:
sysdeps/linux-gnu/mipsel/arch.h |3 ---
Thanks, applied.
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
Sedat Dilek sedat.di...@gmail.com writes:
sysdeps/linux-gnu/mipsel/plt.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Pushed.
Thank you,
PM
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
Hi there,
this week I rewrote the ia64 backend to use fetch interface
(ARCH_HAVE_FETCH_ARG). The current back end worked pretty well overall,
but there were 11 failures in parameters.exp, mostly related to passing
structures in registers, exactly what fetch interface solves.
With the new back
Paul Buerger pbuer...@avetec.org writes:
when -S and -T are specified and if the system call spans
a second boundary, the reported time in the system call
was too large by precisely 2 seconds
I fixed the subject line and whitespace (which was apparently converted
to spaces for some reason;
Andreas Schwab sch...@linux-m68k.org writes:
- break, /* 17 */
+ 17, /* 17 */
Do you know what the deal is here? Why are we giving up a syscall name?
Did Linux discontinue use of those, and if so, when? I.e., couldn't
ltrace
edgar.igles...@gmail.com writes:
I'm posting a few patches that bring the CRIS port back to life.
Thank you, I will apply this. What is the current CRIS status WRT test
suite?
Thank you,
PM
___
Ltrace-devel mailing list
Andreas Schwab sch...@linux-m68k.org writes:
Petr Machata pmach...@redhat.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
- break, /* 17 */
+ 17, /* 17 */
Do you know what the deal is here? Why are we giving up a syscall
Hi there,
some backends (Itanium in particular) change the parameter passing
convention depending on whether given parameter is part of varargs
parameter or not. Therefore the backend needs to know a) that any give
argument is part of parameter pack, and b) if it is, whether it's a
varargs-type
Edgar E. Iglesias edgar.igles...@gmail.com writes:
On Thu, Sep 13, 2012 at 02:39:22PM +0200, Petr Machata wrote:
edgar.igles...@gmail.com writes:
I'm posting a few patches that bring the CRIS port back to life.
Thank you, I will apply this. What is the current CRIS status WRT test
suite
Edgar E. Iglesias edgar.igles...@gmail.com writes:
I've been trying to run ltrace on a MIPS 32r2 little endian system.
I've got a set of patches that work AFAICT. (I'll clean those up
and post them soon).
Great, thank you.
Is anyone else working on this btw? (I should probably have asked
Edgar E. Iglesias edgar.igles...@gmail.com writes:
Yeah, MIPS o32 is a bit different than other archs. The issue with
the PLT is that it is only used when the symbol hasn't been resolved
yet. All code jumps indirectly via GOT entries. At build time, the GOT
entires are built to point into the
Edgar E. Iglesias edgar.igles...@gmail.com writes:
Ran into this:
Running ./ltrace.main/parameters.exp ...
compile failed for ltrace test, ./ltrace.main/parameters.c: In function
'main':
./ltrace.main/parameters.c:196: warning: format '%ld' expects type 'long
int', but argument 4 has type
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
Signed-off-by: Edgar E. Iglesias ed...@axis.com
---
configure.ac |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
That's fine, I'll apply.
PM
___
Ltrace-devel
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
Not all arch's (e.g MIPS) have a direct mapping to
sym-enter_addr.
That looks fine, I'll apply.
Thanks,
PM
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
edgar.igles...@gmail.com writes:
+/* The following callback has to be implemented in backend if arch.h
+ * defines ARCH_HAVE_GET_SYM_INFO.
+ *
+ * This is called for every PLT relocation R in ELF file LTE, that
+ * ltrace is about to add to it's internal representation of the
+ * program
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
to describe symbols with a GOT entry but without PLT
entry.
Signed-off-by: Edgar E. Iglesias ed...@axis.com
---
library.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/library.h
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
Signed-off-by: Edgar E. Iglesias ed...@axis.com
---
sysdeps/linux-gnu/mipsel/plt.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
That is fine, I'll apply.
Thanks,
PM
edgar.igles...@gmail.com writes:
@@ -131,6 +163,9 @@ arch_elf_init(struct ltelf *lte, struct library *lib)
}
}
+ /* Tell the generic code how many dynamic trace:able symbols
+ * we've got. */
+ lte-relplt_count = lte-dynsym_count - lte-arch.mips_gotsym;
edgar.igles...@gmail.com writes:
+#define ARCH_HAVE_ATOMIC_SINGLESTEP
I think I should rename this to ARCH_HAVE_SOFT_SINGLESTEP or some such.
The original intention was to support stepping over lwarx on PPC, but
both MIPS and ARM will need to use this to emulate singlestepping.
+int
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
When functions return we check if the symbol went from
unresolved to resolved and if the resolved address
differs from the unresolved one. If so, we add a new
breakpoint at the resolved address.
I'll need to think
Edgar E. Iglesias edgar.igles...@gmail.com writes:
On Thu, Sep 27, 2012 at 01:36:48AM +0200, Petr Machata wrote:
edgar.igles...@gmail.com writes:
+#define ARCH_HAVE_ATOMIC_SINGLESTEP
I think I should rename this to ARCH_HAVE_SOFT_SINGLESTEP or some such.
The original intention
edgar.igles...@gmail.com writes:
+int
+arch_atomic_singlestep(struct Process *proc, struct breakpoint *sbp,
+int (*add_cb)(void *addr, void *data),
+void *add_cb_data)
+{
+ uint32_t pc = (uint32_t) get_instruction_pointer(proc);
+ uint32_t
edgar.igles...@gmail.com writes:
+/* When functions return we check if the symbol needs an updated
+ breakpoint with the resolved address. */
+void arch_symbol_ret(struct Process *proc, struct library_symbol *libsym)
+{
[...]
+
+ bp = malloc(sizeof (*bp));
+ if (bp == NULL)
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
This is the series I've been hacking on.
I pushed this to master. Thanks for all the work!
There are still issues with threaded apps.
There are at least two issues:
1. Singlestepping over breakpoints is not really
Hi list,
during the development of libs branch (support for tracing inter-library
calls), I broke support for -l. This is now back. -l takes as an
argument a library pattern, the same that -e and -x take after a @. It
only takes a library pattern though, not the full expression, so -l X
means
edgar.igles...@gmail.com writes:
--- a/sysdeps/linux-gnu/mipsel/trace.c
+++ b/sysdeps/linux-gnu/mipsel/trace.c
@@ -202,7 +202,14 @@ int mips_next_pcs(struct Process *proc, uint32_t pc,
uint32_t *newpc)
newpc[nr++] = rx + ((pc + 4) ~0x0fff);
Edgar E. Iglesias edgar.igles...@gmail.com writes:
The patches look good. I've tried to replace the TOPLT_GOTONLY approach
used by MIPS with delayed syms and it works nicely.
Great, thanks. I'll merge after I get your MIPS optimizations in.
The patch looks fine content-wise, but what you sent
Sedat Dilek sedat.di...@gmail.com writes:
Ltracing the dsld-daemon (closed source) on my router box lead
sometimes to stalls and/or my box rebooted. This could be due to
limited RAM as I have approx. 2MiB free.
It is very possible that we leak stuff in ltrace. I'm currently working
on
edgar.igles...@gmail.com writes:
vect_reserve(struct vect *vec, size_t count)
{
if (count vec-allocated) {
- size_t na = vec-allocated != 0 ? 2 * vec-allocated : 4;
+ /* Allocate 4 extra slots for growth. */
+ size_t na = count + 4;
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
Makes it easier to add new types.
Hmm, this was deliberate, but now that there are more back ends alive
than I can hope to take care of personally, your change makes sense.
Any new additions (like 128-bit doubles, vector
Edgar E. Iglesias edgar.igles...@gmail.com writes:
The issue is that if count is large enough, na might not end up as
count triggering the assert. We can keep the exponential growth with
another fix. I didnt realize that was important here.
Ah, I see. I'm hitting this problem with your
Hi there,
on branch pmachata/valgrind are two testsuite fixlets and a patch for
running testsuite under valgrind. This is enabled by --enable-valgrind
passed to configure. The code was essentially cut'n'pasted from
elfutils, original author is Mark Wielaard. I consider this
uncontroversial and
Jackie Yeh [葉龍泉] jackieontra...@gmail.com writes:
Hi Petr,
I applied your patch, and attached the log with -D77 option.
:: fetch_rd32: couldn't read 20 bytes from (nil)
It's strange that 'addr' is a NULL pointer!
Indeed. It loads 0 from DT_DEBUG. What libc are you using? It seems
like
Edgar E. Iglesias edgar.igles...@gmail.com writes:
On Thu, Oct 11, 2012 at 04:44:15PM +0800, Jackie Yeh [葉龍泉] wrote:
Your patches works!
I have to apply patch 1~6, only 1~4 doesn't work.
One question for the patches:
For these patches I copy-and-paste, then save to a patch file, but most
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
When mapping function parameters into argument value dictionaries,
make sure to keep a 1-to-1 mapping between indexes.
For STOP parameters, we insert a ARGTYPE_NONE value to fill out
the argument value dictionary.
edgar.igles...@gmail.com writes:
From: Edgar E. Iglesias ed...@axis.com
Remove the check for generic tags allowing the caller
to pass extension tags. I couldn't find a way to strictly
validate the tag nr, furthermore the seek tag is internally
generated so I simply dropped the check (beyond
edgar.igles...@gmail.com writes:
+/* Are we in pure CPIC mode (the non-PIC ABI extension)? */
+static inline int mips_elf_is_cpic(unsigned int elf_flags)
Function name shoud start a new line.
+ /* FIXME: for CPIC we should really scan both GOT tables
+ * to pick up relocations to
Edgar E. Iglesias edgar.igles...@gmail.com writes:
On Fri, Nov 02, 2012 at 06:07:50PM +0100, Sedat Dilek wrote:
This happens with latest ltrace-git...
./ltrace: proc.c: 755: breakpoint_for_symbol: Assertion `bp-libsym ==
((void *)0)' failed.
I've seen this bug, and I'm actually inclined
Hi there,
the test suite currently cleanly passes on x86's, ppc's, ia64 and
s390's, including 64/3{2,1} cross-tracing scenarios. On x86's, where
valgrind supports ptrace system calls, the test suite was verified to be
leak- and memory error free. On ppc's I made sure that tracing binaries
with
Sedat Dilek sedat.di...@gmail.com writes:
One more thoughts on broken or golden toolchain... gcc's optimization-level.
The Freetz router project uses aggressive -Os by default... I could
try more commonly used -O2.
You are right, it is the -Os that causes this, and it hits on final gcc
as
Andreas Schwab sch...@linux-m68k.org writes:
---
sysdeps/linux-gnu/ppc/Makefile.am | 1 +
1 file changed, 1 insertion(+)
Applied. As I expected, 0.7.1 is due soon for these sorts of nits that
I missed.
Thank you,
PM
___
Ltrace-devel mailing list
Petr Machata pmach...@redhat.com writes:
diff --git a/sysdeps/linux-gnu/mipsel/plt.c b/sysdeps/linux-gnu/mipsel/plt.c
index 7799dfa..7bb00e0 100644
--- a/sysdeps/linux-gnu/mipsel/plt.c
+++ b/sysdeps/linux-gnu/mipsel/plt.c
@@ -251,6 +251,13 @@ void arch_symbol_ret(struct Process *proc, struct
Sedat Dilek sedat.di...@gmail.com writes:
ltrace-0.7.0/sysdeps/linux-gnu/trace.c:908:#if defined __sparc__ ||
defined __ia64___
3x _ for IA64 arch?
Right, there's no such thing as __ia64___. The code works anyway,
apparently ia64 either has hardware singlestepping, or it's emulated in
the
Andreas Schwab sch...@linux-m68k.org writes:
I'm getting a lot of testsuite failures due to
Couldn't determine base address of linux-vdso32.so.1
Couldn't load ELF object linux-vdso32.so.1: No such file or directory
What architecture is this on? Apparently l_name of VDSO in r_debug
linkmap
Andreas Schwab sch...@linux-m68k.org writes:
$ ltrace true
/etc/ltrace.conf:442: error: unknown type around '{
'
/etc/ltrace.conf:443: error: syntax error
/etc/ltrace.conf:444: error: unknown type around 'suseconds_t tv_usec;/*
microseconds */
'
/etc/ltrace.conf:445: error: unknown
Sedat Dilek sedat.di...@gmail.com writes:
On Sat, Nov 10, 2012 at 12:15 AM, Petr Machata pmach...@redhat.com wrote:
Petr Machata pmach...@redhat.com writes:
diff --git a/sysdeps/linux-gnu/mipsel/plt.c b/sysdeps/linux-gnu/mipsel/plt.c
index 7799dfa..7bb00e0 100644
--- a/sysdeps/linux-gnu
Hello,
the tarballs released for 0.7.0 were broken--they weren't made from a
clean checkout, and contained some work-in-progress files from my tree.
I've now corrected the mistake. As previously, new tarballs were
uploaded to:
https://alioth.debian.org/frs/?group_id=30892
The checksums of
Andrey Zonov z...@freebsd.org writes:
When do you plan to release 0.8.0? I just ask because FreeBSD/x86 port
is ready. It would be great to get it in 0.8.0.
There's no fixed date, but soon. End of February? There's no real
hurry, we can wait with 0.8.0 until you get the patches in. I'll
Sedat Dilek sedat.di...@gmail.com writes:
is it possible to get a v0.7.3 - not only for MIPS folks?
Hmm, I think it might make sense... we now support big endian MIPS, and
there's a couple more nits. I'll do it together with 0.8.0.
Regarding that, what should really be in README? Up until
Andrey Zonov z...@freebsd.org writes:
diff --git a/glob.c b/glob.c
index b26637f..06fec47 100644
--- a/glob.c
+++ b/glob.c
@@ -27,7 +27,7 @@
static ssize_t
match_character_class(const char *glob, size_t length, size_t from)
{
- size_t i;
+ size_t i = 0;
if (length 0)
There seems to be something wrong with either your diff program, or your
mailer, or alternatively something mangled it on the way. Maybe try to
post as attachment? I generally prefer inline, but if it's broken...
Thanks,
PM
Andrey Zonov z...@freebsd.org writes:
diff --git a/lens_default.c
Andrey Zonov z...@freebsd.org writes:
I don't see a reason to keep this work in separate branch because it
doesn't touch any other code. I have 3 patches that add FreeBSD/x86
support, I can send them if you like to review.
If you want to have them in official ltrace, then please send them.
Oliver Spornitz ospor...@rz-online.de writes:
Am 16.02.2013 um 15:58 schrieb Oliver Spornitz:
I applied the three patches to the branch ospornit/move_mipsel on top
of the current master.
I missed to move mipsel.h to mips.h in the third commit. I added this
move to that commit an recreated
Sedat Dilek sedat.di...@gmail.com writes:
with latest ltrace upstream GIT I get for my 7170 (mipsel-based) router box:
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'
As a wild guess: did you run ./autogen.sh, make distclean, etc.?
I.e. isn't
Joe Damato ice...@gmail.com writes:
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
Joe Damato ice...@gmail.com writes:
On Tue, Mar 19, 2013 at 6:25 PM, Petr Machata pmach...@redhat.com wrote:
Joe Damato ice...@gmail.com writes:
joe@ubuntu:~/code/ltrace$ /tmp/test/usr/local/bin/ltrace -e* -p 2821
libm.so.6-(0x7fff07366f90, 0x7fff07366f90, 0, -1
Markos Chandras markos.chand...@gmail.com writes:
On 21 March 2013 16:25, Petr Machata pmach...@redhat.com wrote:
Finally, would you please also update README with triplets of systems
where you think ltrace should work with this patch?
The patch already adds this in the README file:
metag
Markos Chandras markos.chand...@gmail.com writes:
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.
Pushed.
Thanks,
PM
Markos Chandras hwoar...@gentoo.org writes:
/bin/sh: line 17: cd: mips: No such file or directory
This is because the mips-mipsel symlink (in sysdeps/linux-gnu) does
not exist in the tarball
We forgot to add that to EXTRA_DIST in sysdeps/linux-gnu/Makefile.am.
I added fix to 0.7 branch. Can
Enrico Scholz enrico.sch...@sigma-chemnitz.de writes:
Due to '-I.', the local 'glob.h' makes it impossible to include the
system wide glob.h header. Patch renames 'glob.h' to avoid this
conflict.
Ugh, you are right, that's not very nice. But would you please rename
it to ltrace-glob.h
Enrico Scholz enrico.sch...@sigma-chemnitz.de writes:
Patch adds an 'include' statement which can be used to include other
I do agree an include mechanism is necessary, but I envision something a
bit different than you.
configuration files recursively. This makes it e.g. possible for
linux
When a library is mapped in, ltrace looks for soname.conf
oh, I was not aware of this feature (and do not find any documentation
about it).
It's now documented it in ltrace.1.
Thanks,
PM
___
Ltrace-devel mailing list
1 - 100 of 213 matches
Mail list logo
