Re: [Ltrace-devel] New ltrace release

2017-02-03 0:27 GMT+01:00 Dima Kogan <d...@secretsauce.net>: > Petr Machata <pmach...@gmail.com> writes: > > I can't devote tons of time to this, but I'm happy to do a release at > least. I think that will be better than the current state. Alioth > username: dkogan I

Re: [Ltrace-devel] New ltrace release

The real reason seems to be lack of resources. I didn't have time to touch ltrace for almost two years now. If somebody else is willing to step in and finalize a release, and the only thing that they are missing is Alioth permissions, I'll be happy to grant those. As things stand, this project

Re: [Ltrace-devel] [PATCH] ltrace: update s390 system call tables

2015-11-06 13:28 GMT+01:00 Heiko Carstens : > just a simple patch for ltrace to add update and fix the system call tables > on s390. In addition this also slightly improves the script to generate > the tables. Thanks, applied. There was some trickery with the

Re: [Ltrace-devel] patch : disable broken printf length

2015-11-11 14:34 GMT+01:00 Mike Dupont : > Attached a dirty patch to disable the broken printf max string length > code. The patch, cleaned up, would make sense to me. > Take a look at _doprnt from libiberty for an implementation. I am We parse the formatting

Re: [Ltrace-devel] Infinite stream of breakpoint events

2015-07-25 0:14 GMT+02:00 Andreas Schwab : > When running the attach-process-dlopen test on ppc64 or ppc64le ltrace > is receiving an endless stream of breakpoint events: > > DEBUG: events.c:336: event: BREAKPOINT: pid=17899, addr=0x3fff88d28c04 > > The last line is repeated

Re: [Ltrace-devel] [PATCH] Fix libunwind support for MIPS

Faraz Shahbazker writes: > On 10/22/2015 02:43 AM, Vicente Olivert Riera wrote: >> ping >> >> On 10/08/2015 04:59 PM, Vicente Olivert Riera wrote: >>> /* Verify that we can safely cast arch_addr_t* to unw_word_t*. */ >>> (void)sizeof(char[1 - 2*(sizeof(unw_word_t) !=

Re: [Ltrace-devel] [PATCH v3] Fix libunwind support for MIPS

Vicente Olivert Riera <vincent.ri...@imgtec.com> writes: > On 24/07/15 08:38, Petr Machata wrote: >> Vicente Olivert Riera <vincent.ri...@imgtec.com> writes: >> >>> >>> rc = unw_get_proc_name(, fn_name, &g

Re: [Ltrace-devel] [PATCH v5] Fix libunwind support for MIPS

2015-08-06 12:08 GMT+02:00 Vicente Olivert Riera : > Tweak the code to make sure the unwind pointers point to the same > address as the arch ones. The patch looks good to me overall. The one outstanding objection that we have is the one regarding the runtime overhead of

Re: [Ltrace-devel] [RFC][PATCH] Add support for mips64 n32/n64

2015-08-04 22:12 GMT+02:00 Faraz Shahbazker <faraz.shahbaz...@imgtec.com>: > On 07/15/2015 03:24 PM, Petr Machata wrote: >> It seems like e_machine and e_class should be /replaced/ with some sort >> of ABI identifier that the backend produces, given an ELF header. The >&

Re: [Ltrace-devel] ltrace on ppc64

Andreas Schwab sch...@linux-m68k.org writes: Petr Machata pmach...@gmail.com writes: It probably should ignore section symbols. I can't decide on the account of object symbols. I don't know off hand if anything that ltrace can actually trace might be represented as STT_OBJECT and we

Re: [Ltrace-devel] [PATCH v2] Fix libunwind support for MIPS

Vicente Olivert Riera vincent.ri...@imgtec.com writes: - int rc = unw_get_reg(cursor, UNW_REG_IP, - (unw_word_t *) ip); + int rc = unw_get_reg(cursor, UNW_REG_IP, uw_ip); + ip = (arch_addr_t)

Re: [Ltrace-devel] [PATCH] Fix libunwind support for MIPS

Vicente Olivert Riera vincent.ri...@imgtec.com writes: /* Verify that we can safely cast arch_addr_t* to unw_word_t*. */ (void)sizeof(char[1 - 2*(sizeof(unw_word_t) != sizeof(arch_addr_t))]); This check will always fail for MIPS 32-bit architectures (the only ones supported by ltrace)

Re: [Ltrace-devel] [PATCH] Install lib*-types.conf

dist_pkgdata_DATA = etc/syscalls.conf etc/libc.so.conf \ - etc/libm.so.conf etc/libacl.so.conf etc/libpthread.so.conf + etc/libm.so.conf etc/libacl.so.conf etc/libpthread.so.conf \ + etc/libpthread.so-types.conf etc/libc.so-types.conf Pushed. Thanks, Petr

Re: [Ltrace-devel] [RFC][PATCH] Add support for mips64 n32/n64

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: diff --git a/proc.h b/proc.h index a611456..00094e1 100644 --- a/proc.h +++ b/proc.h @@ -117,6 +117,7 @@ struct process { * nauseam. */ short e_machine; char e_class; + char e_abi; So the part that the diff

Re: [Ltrace-devel] [PATCH 1/2] The return value of process_line is never used, so make it void

Pushed. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH 2/2] Add a way to force a line to be interpreted as a function prototype

Роман Донченко d...@corrigendum.ru writes: Since import is not a keyword in C, it might be used as a type name. However, a function prototype with import as the return type would be interpreted as an import directive. So provide a new keyword, function, that can be used to force a line to be

Re: [Ltrace-devel] [PATCH] Fix a memory leak in parse_typedef_name

Роман Донченко d...@corrigendum.ru writes: --- a/read_config_file.c +++ b/read_config_file.c @@ -387,6 +387,7 @@ parse_typedef_name(struct protolib *plib, struct locus *loc, char **str) return NULL; struct named_type *nt = protolib_lookup_type(plib, buf, true); +

Re: [Ltrace-devel] [PATCH] Add more libpthread.so definitions

Роман Донченко d...@corrigendum.ru writes: Enclosing as an attachment due to potential line wrapping issues. Pushed. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org

Re: [Ltrace-devel] [PATCH 4/6] Split type definitions from the bundled configs into their own files

Роман Донченко d...@corrigendum.ru writes: http://lists.alioth.debian.org/pipermail/ltrace-devel/2015-April/001298.html. Pushed. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org

Re: [Ltrace-devel] [PATCH 1/6] Fix a memory leak in protolib_cache_maybe_load

Роман Донченко d...@corrigendum.ru writes: - if (DICT_FIND_VAL(cache-protolibs, key, retp) == 0) + if (DICT_FIND_VAL(cache-protolibs, key, retp) == 0) { + if (*retp != NULL own_key) + free((void *) key); return 0; + } if (strdup_if(key,

Re: [Ltrace-devel] [PATCH 2/6] Make sure there's at least one space after typedef when parsing

Роман Донченко d...@corrigendum.ru writes: For the record, I thought this was okay, because eat_spaces doesn't recognize tabs either. You might want to fix that, too. Good point. I think that's an omission. I changed it to use isspace. Thanks, Petr

Re: [Ltrace-devel] [PATCH 6/6] Document import directives

Pushed. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH 1/6] Fix a memory leak in protolib_cache_maybe_load

Роман Донченко d...@corrigendum.ru writes: When a non-NULL protolib is returned and own_key is true, the key must be freed. --- prototype.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/prototype.c b/prototype.c index fa52ff3..22e54c4 100644 --- a/prototype.c

Re: [Ltrace-devel] [PATCH] Fix an uninitialized memory access in parse_lens

I decided name2lens is not really adding much value (it's very simple and with one call site only), so I inlined the loop to parse_lens. That's now on master. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org

Re: [Ltrace-devel] [PATCH] Fix XDG_CONFIG_DIRS.exp failing when ltrace needs LD_LIBRARY_PATH to run

Pushed. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH] Fix spurious failures in attach-process.exp

Pushed. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] ltrace overhead

yogender nerella ynere...@gmail.com writes: I have googled a lot and dont really find any great c++ profiling tools ( free), do you recommend any? Check out perf and oprofile. ltrace suggests most of our application is spent on memcmp, but by looking at our code, we don't see that as a

Re: [Ltrace-devel] ltrace overhead

yogender nerella ynere...@gmail.com writes: I am profiling a large application involving oracle database libraries. Without any tracing my program completes in 2 to 3 minutes, but with ltrace it is taking over 2 to 3 hours. ltrace is not a great tool for profiling. Every event implies a

Re: [Ltrace-devel] [PATCH RESEND] Add POSIX Threads prototypes

Роман Донченко d...@corrigendum.ru writes: copious free time. ;) Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH RESEND] Add POSIX Threads prototypes

Роман Донченко d...@corrigendum.ru writes: Petr Machata pmach...@redhat.com писал в своём письме Thu, 12 Mar 2015 00:25:36 +0300: Also, you don't want to simply call read_config_file recursively, as that would re-read the file every time it's included. You also still want to allow the full

Re: [Ltrace-devel] [PATCH RESEND] Add POSIX Threads prototypes

Роман Донченко d...@corrigendum.ru writes: Hmm... maybe. Could you point me to what you mean by the existing low-level functionality? I'm thinking I could add a new type of line (e.g. include) and recursively call read_config_file when handling one. Is there anything that's already done for

Re: [Ltrace-devel] [PATCH] Remove void argument lists from libpthread.so.conf

Pushed. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH] [MIPS] Detect return from rt_sigreturn syscalls

Sedat Dilek sedat.di...@gmail.com writes: Is the PLT-less MIPS binaries support upstream? It is upstream. It hasn't been merged do master. Faraz, just to clear things up, the branch is mostly yours, despite the name. I don't know much about MIPS and don't have a Linux-capable hardware handy.

Re: [Ltrace-devel] [PATCH] [MIPS] Detect return from rt_sigreturn syscalls

Pushed. ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH] [MIPS] Detect return from rt_sigreturn syscalls

The patch looks good to me. I'd wait a bit for Eugene feedback so that you two can figure out any low-hanging fruit, otherwise I'll push tomorrow. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org

Re: [Ltrace-devel] [PATCH v3] Tracing PLT-less MIPS binaries

Eugene Rudoy g...@freetz.org writes: Is it something already implemented in master? Would merging pmachata/mips to master solve the issue? Or should mips backend (properly) implement some new-style fetch backend-callbacks? MIPS would have to implement fetch backend. I suspect that most of

Re: [Ltrace-devel] [PATCH v3] Tracing PLT-less MIPS binaries

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: On 02/09/2015 03:24 AM, Eugene Rudoy wrote: I had no problems applying it on top of cf55336f3d. I however had to remove an extra ) before in the following fragment (part of arch_dynlink_done) in order to get it compiled. That was the

Re: [Ltrace-devel] [PATCH v3] Tracing PLT-less MIPS binaries

Eugene Rudoy g...@freetz.org writes: # result: terminates with snprintf(./ltrace: value.c: 343: value_set_word: Assertion `sz = sizeof(value-u.value)' failed. This looks related to the missing new-style fetch backend. There's a small wrapper layer that translates the new-style fetch_* calls

Re: [Ltrace-devel] [PATCH v3] Tracing PLT-less MIPS binaries

Sedat Dilek sedat.di...@gmail.com writes: Against which Git branch is this patch? pmachata/mips? That would be the natural choice at this point. But actually the patch doesn't apply for me as it is. For some reason the following hunk is ill-formed: @@ -406,37 +406,11 @@

Re: [Ltrace-devel] [PATCH v2] Tracing PLT-less MIPS binaries

Sedat Dilek sedat.di...@gmail.com writes: nice to see this making progress. Is this still against pmachata/mips Git branch? Yes. Does it need some extra patches you posted? No. Is this RFC? All patches are ;) Can you send out a patch with git send-email even it is RFC That's what he

Re: [Ltrace-devel] [PATCH v2] Tracing PLT-less MIPS binaries

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: To capture the last one, I've added a check for whether proc-pid occurs in options.h:opt_p - not sure if there is a simpler way of performing this check. Both a -p and a command can be given. Probably not something that would typically be

Re: [Ltrace-devel] [PATCH v2] Tracing PLT-less MIPS binaries

Sedat Dilek sedat.di...@gmail.com writes: Why should I git-apply the patch, extract snippets into this email and then comment myself on them - isn't that a bit complicated :-)? Oh, I see, you would like it inline instead of as an attachment. Sorry, I didn't understand what you meant the first

Re: [Ltrace-devel] [PATCH] Fix missing includes and return statements in test sources

Applied. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] ppc64le filt test hangs

Thierry fa...@linux.vnet.ibm.com thie...@linux.vnet.ibm.com writes: Any thought on how to debug what's going on ? Get a minimal reproducer (ideally tracing a single symbol in a small binary), then look through -D77, and annotate, annotate, annotate. You can in theory debug ltrace under gdb,

Re: [Ltrace-devel] [PATCH v2] Tracing PLT-less MIPS binaries

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: +#define inrange(x,lo,hi) ((x)=(hi) (x)=(lo)) +static int +mips_atomic_next_pcs(struct process *proc, uint32_t pc, uint32_t *newpcs) +{ + uint32_t spc, lladdr = pc, scaddr = pc + 4; + int nr = 0; + + for (lladdr = pc;

Re: [Ltrace-devel] [PATCH] Tracing PLT-less MIPS binaries

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: As far as the linker code for MIPS is concerned I don't even see a single jump. Any atomic sequence that has a branch can be written as 2 shorter sequences with the branch decision performed earlier. Besides, we always want atomics to be as

Re: [Ltrace-devel] [PATCH] Tracing PLT-less MIPS binaries

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: On 01/21/2015 02:44 PM, Petr Machata wrote: So it seems to me this logic should be folded into mips_next_pcs, and only activated when the stepped-over instruction is an LL. ... I think ltrace currently support two breakpoints for software

Re: [Ltrace-devel] [PATCH] Tracing PLT-less MIPS binaries

Thanks for the patch. Most of it looks good, but I have some points about the software singlestepping. Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: diff --git a/sysdeps/linux-gnu/mips/trace.c b/sysdeps/linux-gnu/mips/trace.c index 88e13ac..1e462d0 100644 ---

Re: [Ltrace-devel] Current status of git tree on ppc64le

Thierry fa...@linux.vnet.ibm.com thie...@linux.vnet.ibm.com writes: * With GGC 4.9.2 , we get a message: /tmp/lt-V2vnjpabM5.c:73:10: note: the ABI of passing homogeneous float aggregates will change in a future GCC release Per this commit:

Re: [Ltrace-devel] Current status of git tree on ppc64le

Petr Machata pmach...@redhat.com writes: It's not pushed yet, I got distracted by some bugs in Dwarf backend that that I noticed when re-testing. Pushed now. The dwarf tests pass for me now on x86_64 Fedora 21. Thanks, Petr ___ Ltrace-devel

Re: [Ltrace-devel] [PATCH] dict entries lost due to erase

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: I have observed random failures with PIC, when looking up breakpoints. It looks like find_slot() doesn't search far enough in to the dictionary before giving up, after an item has been erased. Patch enclosed with a simple test-case.

Re: [Ltrace-devel] missing library traces

Faraz Shahbazker faraz.shahbaz...@imgtec.com writes: On Fri, Jan 2, 2015 at 1:54 PM, Petr Machata pmachata at redhat.com wrote: It seems like I wanted to redo what PowerPC (and newly Xtensa!) was/is doing with unresolving PLT slots when they are resolved, so that we don't have to move

Re: [Ltrace-devel] [Linux-Xtensa] [PATCH v2] xtensa: add xtensa support

Marc Gauthier m...@cadence.com writes: I think overlays map multiple sections at the same address, presumably the assumption is that overlays are not used in the context of ltrace? (They're not particularly useful with Linux, although one might imagine some use in uC-Linux, which we haven't

Re: [Ltrace-devel] missing library traces

Sedat Dilek sedat.di...@gmail.com writes: Can you give Oliver appropriates credits in CREDITS file? Absolutely. Oliver, send me a patch, please. Thanks, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org

Re: [Ltrace-devel] [PATCH v3] xtensa: add xtensa support

Applied. Thank you, Petr ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH v2] xtensa: add xtensa support

Max Filippov jcmvb...@gmail.com writes: On Sat, Jan 3, 2015 at 5:53 PM, Petr Machata pmach...@redhat.com wrote: Max Filippov jcmvb...@gmail.com writes: On Fri, Jan 2, 2015 at 4:32 AM, Petr Machata pmach...@redhat.com wrote: +int +arch_elf_init(struct ltelf *lte, struct library *lib

Re: [Ltrace-devel] missing library traces

Sedat Dilek sedat.di...@gmail.com writes: On Thu, Jan 16, 2014 at 9:20 PM, Petr Machata pmach...@redhat.com wrote: Eugene Rudoy g...@freetz.org writes: as to compiling the master: I had to apply the two patches attached to this mail in order to compile it (I simply removed that lte

Re: [Ltrace-devel] [PATCH v2] xtensa: add xtensa support

Max Filippov jcmvb...@gmail.com writes: - drop gimme_arg and implement arch_fetch_* callbacks; Cool. - add diagnostics to {get,set}_instruction_pointer, get_stack_pointer and get_return_addr; - update CREDITS, NEWS and README. Changes RFC-PATCH: - adopt PLT unresolving algorithm used

Re: [Ltrace-devel] [PATCH v2] xtensa: add xtensa support

Max Filippov jcmvb...@gmail.com writes: On Tue, Dec 9, 2014 at 2:34 AM, Max Filippov jcmvb...@gmail.com wrote: Signed-off-by: Max Filippov jcmvb...@gmail.com --- Changes v1-v2: - drop gimme_arg and implement arch_fetch_* callbacks; - add diagnostics to {get,set}_instruction_pointer,

Re: [Ltrace-devel] Compilation error with ltrace head

Thierry fa...@linux.vnet.ibm.com thie...@linux.vnet.ibm.com writes: In file included from library.h:32:0, from library.c:30: library.c: In function 'library_dump_symbols': dict.h:223:25: error: passing argument 1 of 'dict_each' discards const' qualifier from pointer target

Re: [Ltrace-devel] DWARF test suite

Dima Kogan li...@dima.secretsauce.net writes: At the end of dwarf.exp I was looking for ft...@libc.so.6(0x[0-9a-z]*) * = -1 Note the ' * ' with 1 space on either side of *. In your tree you changed it to ' * '. This is in two places at the end of that file. Curious. The rest of

Re: [Ltrace-devel] DWARF test suite

Dima Kogan li...@dima.secretsauce.net writes: Hi. I just uploaded a patch that does the filename-language-choice as you suggested: .c11 is C 11 .cc11 is C++ 11 .cc, .cpp is C++ (whatever gcc has as the default) This choice is still in ltrace.exp. The DWARF-specific piece simply

Re: [Ltrace-devel] Restricting functions printed by ltrace

Reposting with Victor's permission: Victor Porton por...@narod.ru writes: 12.08.2014, 11:12, Petr Machata pmach...@redhat.com: Victor Porton por...@narod.ru writes:  I use  ltrace -n4 -A10 -llibraptor2.so.0 ./obj/test/debug/run_all_tests 21| egrep ^[a-z]  to output only these calls

Re: [Ltrace-devel] [PATCH] Add support for using elfutils as unwinder.

Andreas Schwab sch...@linux-m68k.org writes: It would, if it would apply. How about this? diff --git a/dwarf_prototypes.c b/dwarf_prototypes.c index 9c36904..a39219e 100644 --- a/dwarf_prototypes.c +++ b/dwarf_prototypes.c @@ -8,6 +8,7 @@ #include stdio.h #include elfutils/libdwfl.h

Re: [Ltrace-devel] Compilation error with dwarf code

Kai Noda noda...@gmail.com writes: Kai Noda noda...@gmail.com writes: +#if defined(HAVE_LIBDW) #include dwarf_prototypes.h +#endif /* defined(HAVE_LIBDW) */ I don't think these two lines constitute a creative work protected by copyright laws. No authorship/copyright claimed. OK,

Re: [Ltrace-devel] [PATCH] PPC: fix PPC32 build

Pushed. Thanks, PM ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] Config files

Dima Kogan li...@dima.secretsauce.net writes: Hi all. In putting together the test suite, I hit a few issues with conf files. Those are all described together in this email. When running the test suite, I would think we want to be testing the build of ltrace that appears in the checked-out

Re: [Ltrace-devel] ltrace not working on some shared objects

Patric Schmitz bzk0...@aol.com writes: that easily, so I'm kinda stuck here. What might be reasons for ltrace not being able to trace calls in-between linked shared objects? ltrace doesn't show calls from shared libraries by default, but you can configure that it does. You could just say -e

Re: [Ltrace-devel] DWARF prototypes: handling symbol aliases

Dima Kogan li...@dima.secretsauce.net writes: I fixed this, and the tree now has another patch. I merged your code. I also fixed a bug where lib-dwfl_module was left uninitialized on clone. main-vfork.exp was failing on that (in fact it has been like that for some time now). This somewhat

Re: [Ltrace-devel] ltrace not working on some shared objects

Patric Schmitz bzk0...@aol.com writes: On Fri, 25 Jul 2014 11:03:36 +0200 Petr Machata pmach...@redhat.com wrote: Patric Schmitz bzk0...@aol.com writes: that easily, so I'm kinda stuck here. What might be reasons for ltrace not being able to trace calls in-between linked shared objects

Re: [Ltrace-devel] [PATCH] xtensa: add xtensa support

This looks good. I'm ready to merge this code-wise. But please mention xtensa support in README and NEWS, and if you care, add yourself to CREDITS (the list is alphabetical by last name). Sending these additions as an additional patch is fine by me, depends on what you prefer. Max Filippov

Re: [Ltrace-devel] [RFC] add xtensa architecture support to ltrace

Max Filippov jcmvb...@gmail.com writes: It's an RFC because currently there's an issue I'm not sure how to deal with: code blocks that correspond to PLT entries on other architectures are only used at most once on xtensa, after initial resolution of imported symbol address importing module

Re: [Ltrace-devel] Addition to the manpage

Dima Kogan li...@dima.secretsauce.net writes: OK. New patch pushed up. Merged. Thanks, PM ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] Addition to the manpage

Dima Kogan li...@dima.secretsauce.net writes: Do you think this is better? I can go either way. Well, this only adds the exited messages, and I find it better that you don't hide anything from the user. The added exited is no distraction at all, I think. I would also put the whole example in

Re: [Ltrace-devel] DWARF prototypes: handling symbol aliases

Dima Kogan li...@dima.secretsauce.net writes: Hi. This code wasn't pushed anywhere, but if you want to look at it, it's here: https://github.com/dkogan/ltrace/tree/libsym_aliases_inexportlist Took a look now. Looks reasonable. The iterator interfaces that you have seem unlike what's in

Re: [Ltrace-devel] [PATCH V04 ] Support for ppc64le (Little Endian and ABIv2)

Applied. Thanks for following through on this, PM ___ Ltrace-devel mailing list Ltrace-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel

Re: [Ltrace-devel] [PATCH] Support for ppc64le (Little Endian and ABIv2) Add new testsuite/ltrace.main/parameters-str.exp file Handles HFA and irelative support

Thierry Fauck ( thierry @ linux.vnet.ibm.com ) thie...@linux.vnet.ibm.com writes: +#ifndef EF_PPC64_ABI +# define EF_PPC64_ABI 3 +#endif Shouldn't I had this defintion is arch.h when I am not in case _CALL_ELF==2 so when I want to use it I can bail out if EF_PPC_ABI undefined in

Re: [Ltrace-devel] Getting prototypes from debug information

Mark Wielaard m...@redhat.com writes: On Sun, 2014-05-11 at 23:12 +0200, Petr Machata wrote: My mistake, I thought we have a Dwfl per process, but we have one per library. Having it stored at process would perhaps fit better with the overall design of Dwfl, but I guess there's no bug

Re: [Ltrace-devel] Getting prototypes from debug information

Mark Wielaard m...@redhat.com writes: On Mon, 2014-05-12 at 16:36 +0200, Petr Machata wrote: I see it now. So correct me if I'm wrong, but that means that after the first dwfl_report_elf, dwfl_nextcu would iterate over just that one module. However after second dwfl_report_elf, dwfl_nextcu

Re: [Ltrace-devel] [PATCH] Support for ppc64le (Little Endian and ABIv2) Add new testsuite/ltrace.main/parameters-str.exp file Handles HFA and irelative support

Thierry, will you be able to address these last nits? It's the last hump before I can merge this without breaking compilation on hosts that don't know about ELFv2 ABI yet. Thank you, PM Petr Machata pmach...@redhat.com writes: This looks all pretty good. I compile-tested it on plain PPC64

Re: [Ltrace-devel] Getting prototypes from debug information

Dima Kogan li...@dima.secretsauce.net writes: This doesn't seem right. dwfl_nextcu should go through all CU's of the whole Dwfl--i.e. if you add two Dwarf-based libraries to a process, it would iterate the former one twice. Or maybe I don't quite grasp how your code works. I'm not trying

Re: [Ltrace-devel] Getting prototypes from debug information

Dima Kogan li...@dima.secretsauce.net writes: Rebased. OK, merged. I forgot about one more thing: please add a NEWS item for your change and, if you care, a CREDITS entry for yourself as well. Thanks, PM ___ Ltrace-devel mailing list

Re: [Ltrace-devel] Getting prototypes from debug information

Dima Kogan li...@dima.secretsauce.net writes: I looked into this, and it's caused by the thread. If you modify your main() in hle1.c to do pthread_create() and call jedna() from the thread, then the in-second-thread jedna() call is shown with the default prototype. This is with 'ltrace -f

Re: [Ltrace-devel] [PATCH] Support for ppc64le (Little Endian and ABIv2) Add new testsuite/ltrace.main/parameters-str.exp file Handles HFA and irelative support

This looks all pretty good. I compile-tested it on plain PPC64 --it's desirable to keep ltrace building on old toolchains as well-- and hit a couple problems with the several new symbols that you use. I think we should have a fallback that disables the new code if the definitions are just

Re: [Ltrace-devel] Getting prototypes from debug information

Dima Kogan li...@dima.secretsauce.net writes: Petr Machata pmach...@redhat.com writes: So this is the result of my advice to only look to immediate protolib when looking up prototypes. It seems you need to look recursively after all. (Which should just mean passing true

Re: [Ltrace-devel] Getting prototypes from debug information

Mark Wielaard m...@redhat.com writes: On Thu, 2014-04-24 at 01:48 +0200, Petr Machata wrote: You're right, I'm not sure what I was looking at. I don't see it as udata now either. Maybe you were using a trunk GCC compiler? Nope, pretty sure it was 4.8.2. Must have been some sort of thinko

Re: [Ltrace-devel] Quick question about conf file

Thierry fa...@linux.vnet.ibm.com thie...@linux.vnet.ibm.com writes: I get a corner case where a function returns a struct of string 16 Bytes, I get an optimization. What should be the conf file to have in the info structure the size of the string ? is struct(array(char,16))

Re: [Ltrace-devel] Getting prototypes from debug information

Dima Kogan li...@dima.secretsauce.net writes: - added a disabled stub for complex float support. ltrace itself doesn't have complex lenses yet. I'd like to get the core of this new DWARF functionality working, then build extra things on it. Thus I'd like to punt on this one until later

Re: [Ltrace-devel] Getting prototypes from debug information

Petr Machata pmach...@redhat.com writes: What we are using is very close to what Linux kernel coding style looks like. One more thing, opening curly braces should be placed at the end of the line, except for functions. (This is the same that Linux kernel does.) - in getEnum, you assume

Re: [Ltrace-devel] Support for ppc64el patch

Thierry fa...@linux.vnet.ibm.com thie...@linux.vnet.ibm.com writes: @@ -34,7 +34,29 @@ #ifdef __powerpc64__ // Says 'ltrace' is 64 bits, says nothing about target. #define LT_ELFCLASS2 ELFCLASS64 #define LT_ELF_MACHINE2 EM_PPC64 -#define ARCH_SUPPORTS_OPD + +#ifdef

Re: [Ltrace-devel] git branch w/ some missing includes

dann frazier da...@debian.org writes: I posted some patches yesterday that added some missing includes in the new aarch64 code (held for moderation since I wasn't yet sub'd). I've posted my git branch here if you'd prefer to merge from there: https://github.com/dannf/ltrace Sorry, I

Re: [Ltrace-devel] ltrace update for ppc64el arch (Petr Machata)

Thanks, this will save me quite a bit of work figuring out how the new ABI works. Thierry@vnet thie...@linux.vnet.ibm.com writes: diff --git a/ltrace-0.7.3.orig/sysdeps/linux-gnu/ppc/arch.h b/ltrace-0.7.3/sysdeps/linux-gnu/ppc/arch.h index fb8768a..edabe2e 100644 ---

Re: [Ltrace-devel] Error in last patch for ltrace ABIv2

Thierry@vnet thie...@linux.vnet.ibm.com writes: 1) The change to config.guess and libtool.m4 are supposed to be done, if not let me know. Those look fine to me. You might want to post those separately, but depends on you, I don't mind having them in one bunch with the rest of ELFv2

Re: [Ltrace-devel] Git errors this week-end

Thierry@vnet thie...@linux.vnet.ibm.com writes: git clone git://git.debian.org/git/collab-maint/ltrace.git Cloning into 'ltrace'... fatal: protocol error: bad line length character: It works for me now. Must have been a blip. Thanks, PM ___

Re: [Ltrace-devel] Current dev. tree tes run

Thierry@vnet thie...@linux.vnet.ibm.com writes: I worked this morning with the current dev. tree on ppc64 and i386 and both are failing the ./ltrace.main/system_calls.exp with the error : FAIL: ^(new|f)?stat(64)?$ was recorded 2 times, expected == 1 Looking at the output we find 2

Re: [Ltrace-devel] Work on bug #135985 - ltrace could catch library-to-library calls

Jevin Sweval jevinswe...@gmail.com writes: This is a feature that I would really like to see! I'm not sure where to start working though. This should generally work in ltrace 0.7.0 or later. Use ltrace -e@ to tell ltrace that you want to trace calls from all libraries (the empty string before

[Ltrace-devel] Some MIPS backend work

This e-mail went out over a week ago. I noticed just now that I forgot to CC: the ltrace devel list, so I'm resending it. I haven't had a chance to work on the MIPS backend since I wrote this. -- Hi there, I had a chance to look into MIPS tracing on Sunday. For the PLT-ful case we can

Re: [Ltrace-devel] missing library traces

Oliver Metz oli...@freetz.org writes: Is this a ltrace bug? What information can I provide to help to fix it? Or does our toolchain misbehave? I read some mails from Sedat in the archives about the PLT topic but nothing the helped me to solve this issue. You can find some more information in

Re: [Ltrace-devel] missing library traces

Eugene Rudoy g...@freetz.org writes: as to compiling the master: I had to apply the two patches attached to this mail in order to compile it (I simply removed that lte-relplt_count-line). Hmm, the _GNU_SOURCE ones probably make sense (see the comment about uclibc above one of them). As to

Re: [Ltrace-devel] [PATCH] Add support for using elfutils as unwinder.

Mark Wielaard m...@redhat.com writes: In the ltrace case it might just be enough to print [...] in case of any error to indicate we don't know whether or not there should be more frames (beyond the -w NR limit). I still wonder what your opinion is though. It seems as if

  1   2   3   >