Re: [Ltrace-devel] No output on Ubuntu 16.10

Hi. I just did this a different way: made a new yakkety chroot with debootstrap: sudo debootstrap --variant=minbase yakkety yakkety_amd64 http://mirror.math.ucdavis.edu/ubuntu/ This creates a fresh system, and I can then chroot into it. ltrace works OK here. The MD5 hash of the stock

Re: [Ltrace-devel] No output on Ubuntu 16.10

Stefano Cristalli writes: > I post to this list with the hope to solve the problem I posted > yesterday on Stack Overflow: > http://stackoverflow.com/questions/43213505/no-output-when-running-ltrace > > ltrace (installed either from package or from source) shows no

Re: [Ltrace-devel] New ltrace release

Petr Machata writes: > 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

Re: [Ltrace-devel] New ltrace release

9128a6fb Mon Sep 17 00:00:00 2001 From: Dima Kogan <d...@secretsauce.net> Date: Fri, 8 Apr 2016 16:12:25 -0700 Subject: [PATCH] void struct members are now ignored Previously the dwarf parser would crash when encountering such a thing --- dwarf_prototypes.c | 5 + 1 file changed, 5 inserti

Re: [Ltrace-devel] DWARF test suite

Petr Machata pmach...@redhat.com writes: I reworked the branch into a couple pieces that I feel belong together and fixed those minor issues. Hi. I see one small discrepancy. 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

Re: [Ltrace-devel] DWARF test suite

Petr Machata pmach...@redhat.com writes: Dima Kogan li...@dima.secretsauce.net writes: If I removed the gnu++11 part from the ltrace.exp patch, and put that into dwarf.exp somehow, then we're good? Yes. In the new-style tests (e.g. parameters2.exp), we use file ending to determine what's

[Ltrace-devel] DWARF test suite

Hi. Thank you for merging the aliased symbol branch, Petr. I added a simple test for the DWARF code into the test suite, and it appears in the master branch of g...@github.com:dkogan/ltrace.git There are several other commits in that branch that do various useful things. They didn't seem

[Ltrace-devel] Config files

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 source tree, and that it should be independent of

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

Petr Machata pmach...@redhat.com writes: Dima Kogan li...@dima.secretsauce.net writes: We could actually store vectors in the hash table directly. The reason I did it this way was to reduce the memory inefficiency of the hash table. [...] Still want this change? That's a good point. I'm

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

Petr Machata pmach...@redhat.com writes: Sorry this took so long again. I'm a fresh father and things have been hectic the last two weeks or so. That's ok, course. Thank you for putting in the work you have been. I was busy, so likewise sorry for the delay. I addressed your points. The new

Re: [Ltrace-devel] Addition to the manpage

Petr Machata pmach...@redhat.com writes: Dima Kogan li...@dima.secretsauce.net writes: Hi. I added a section to the manpage giving an example of the effects of -l, -x and -e. It's here: https://github.com/dkogan/ltrace/tree/manpage This looks good. I wonder about the effect of grep

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

Petr Machata pmach...@redhat.com writes: Dima Kogan li...@dima.secretsauce.net writes: 2. Find the aliases in 'exported_names'. This requires a fancier data structure for 'exported_names'. I have implemented #2, and it works. The code was a bit of a pain to write, and it needs cleanup

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

Dima Kogan li...@dima.secretsauce.net writes: As noted in the previous thread, there's an issue with parsing the prototypes from the DWARF data caused by multiple symbol names referring to the same address. I looked at this a bit more, and have some working prototype code, and I'd like some

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

Petr Machata pmach...@redhat.com writes: 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

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

Thierry Fauck ( thierry @ linux.vnet.ibm.com ) thie...@linux.vnet.ibm.com writes: I also got this message if I don't have the proper libraries In file included from proc.c:39:0: dwarf_prototypes.h:4:30: fatal error: elfutils/libdwfl.h: No such file or directory #include elfutils/libdwfl.h

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

New version pushed. Comments inline. Petr Machata pmach...@redhat.com writes: You addressed the *-at-variable in function prototypes, but this should apply everywhere Please drop the extra spaces. I thought I took care of those earlier. In any case, those should be fixed now. +

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

Petr Machata pmach...@redhat.com writes: Is there a reason not to just use uint64_t for encoding? Nope. Typo. Then this doesn't need the cast ;) oh yeah. One last thing. Can you please: $ git remote add debian git://git.debian.org/git/collab-maint/ltrace.git $ git fetch debian $ git

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

Petr Machata pmach...@redhat.com writes: 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

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

Petr Machata pmach...@redhat.com writes: Dima Kogan li...@dima.secretsauce.net writes: The command at this point is ./ltrace -f [DK: forgot '-f' in the original email] -l 'libjpeg.so*' /usr/bin/geeqie /tmp/small.jpg Second, running this way reports libjpeg-libjpeg calls correctly

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

Petr Machata pmach...@redhat.com writes: By the way, looking into dwarf_prototypes.c, I see a number of style points that will need addressing before this is accepted: Hi. I patched the sources to take your style suggestions. I also rebased to remove the temporary void*-printing fix:

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

I plugged all my memory leaks. Stuff still leaks, but nothing new that I introduced. Some comments inline. Dima Kogan li...@dima.secretsauce.net writes: 1. filter_matches_symbol() and dwlf is leaking. Every time I call these we leak a bit. The dwfl is out of our hands

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

Petr Machata pmach...@redhat.com writes: -e traces PLT calls (i.e. inter-library calls), -x traces symbol entry points. -l traces PLT calls done to a symbol defined by a library in -l. Can we add this to the manpage? I don't feel qualified to do this myself yet. How about this? diff

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

Petr Machata pmach...@redhat.com writes: Dima Kogan li...@dima.secretsauce.net writes: - If I define the type in libwhatever.so.conf then it works. If I define the type in .ltrace.conf, it doesn't work (DWARF definition used). If I define it in both, the it STILL doesn't work. Not sure

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

Dima Kogan li...@dima.secretsauce.net writes: OK. My near-term todo list: - Try to get prototypes from both DWARF and conf files. I ran some tests, and pushed some new patches to that same tree. Some joint .conf/DWARF prototyping now works! I can now prototype a function in a .conf file

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

Petr Machata pmach...@redhat.com writes: The integration with conf-based protolibs is kinda tricky. What we currently do for somelib.so.1.2.3 is look for somelib.so.1.2.3.conf, then somelib.so.1.2.conf, then somelib.so.1.conf, and then somelib.so.conf. I think it's only there that we should

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

Petr Machata pmach...@redhat.com writes: Dima Kogan li...@dima.secretsauce.net writes: Currently it appears that all function prototypes are read from the .conf files. Can these be read in from the debug information instead? They sure can. ltrace already uses libdw, so I'm assuming either