Re: [patch 0/3] Live PIDs with deleted files by /dev/PID/mem

2014-02-26 Thread Jan Kratochvil
On Wed, 26 Feb 2014 17:42:26 +0100, Mark Wielaard wrote: > I'll try and understand what I was trying to do, > clean it up and post it, if it looks useful/sane. OK, I think we can talk about it even in abstract. The primary problem of bfd_from_remote_memory (bfd/elfcode.h) always IMO was that it d

Re: [patch 0/3] Live PIDs with deleted files by /dev/PID/mem

2014-02-26 Thread Mark Wielaard
On Wed, 2014-02-26 at 17:37 +0100, Jan Kratochvil wrote: > On Wed, 26 Feb 2014 17:29:38 +0100, Mark Wielaard wrote: > > I got something somewhat working some time back, but I don't understand my > > own patches... (most are really just lots of extra debug output). > > And are those patches posted

Re: [patch 0/3] Live PIDs with deleted files by /dev/PID/mem

2014-02-26 Thread Jan Kratochvil
On Wed, 26 Feb 2014 17:29:38 +0100, Mark Wielaard wrote: > I got something somewhat working some time back, but I don't understand my > own patches... (most are really just lots of extra debug output). And are those patches posted somewhere? Jan

Re: [patch 0/3] Live PIDs with deleted files by /dev/PID/mem

2014-02-26 Thread Mark Wielaard
On Tue, 2014-02-25 at 23:03 +0100, Mark Wielaard wrote: > On Sat, 2014-02-22 at 22:08 +0100, Jan Kratochvil wrote: > > This patchset (/dev/PID/mem solution) works only on recent Linux kernels > > (tested kernel-3.13.3-201.fc20.x86_64) as older kernels (RHEL-6) required > > PTRACE_ATTACHed PID to re

[PATCH] libdwfl: linux-proc-maps.c (proc_maps_report): Don't assert on bad input.

2014-02-26 Thread Mark Wielaard
If ino == last_ino && dmajor == last_dmajor && dminor == last_dminor then we expect the file names to be the same as well. Which is reasonable if the input came from the /proc file system. But there could be bad user input if the file was supplied through dwfl_linux_proc_maps_report. Instead of ass

Re: elfutils/libdw ARM compilation (native and cross compile)

2014-02-26 Thread Jean Pihet
Mark, Jan, On 26 February 2014 10:13, Mark Wielaard wrote: > On Wed, 2014-02-26 at 09:18 +0100, Jean Pihet wrote: >> While at it, I have a concern about the compat mode: profiling an >> ARMv7 binary on an ARMv8 system. >> Is this supported by libdw? > > My ARM terminology is not that great, but a

Re: elfutils/libdw ARM compilation (native and cross compile)

2014-02-26 Thread Mark Wielaard
On Wed, 2014-02-26 at 09:18 +0100, Jean Pihet wrote: > While at it, I have a concern about the compat mode: profiling an > ARMv7 binary on an ARMv8 system. > Is this supported by libdw? My ARM terminology is not that great, but assuming ARMv7 is 32-bit (AARCH32?)and ARMv8 is 64-bit (AARCH64), then

Re: elfutils/libdw ARM compilation (native and cross compile)

2014-02-26 Thread Jan Kratochvil
On Wed, 26 Feb 2014 09:18:44 +0100, Jean Pihet wrote: > While at it, I have a concern about the compat mode: profiling an > ARMv7 binary on an ARMv8 system. > Is this supported by libdw? elfutils target support is always independent of the host. And every build of elfutils always contains all the

Re: elfutils/libdw ARM compilation (native and cross compile)

2014-02-26 Thread Jean Pihet
While at it, I have a concern about the compat mode: profiling an ARMv7 binary on an ARMv8 system. Is this supported by libdw? I know you can do it with libunwind by linking multiple libraries, cf. [1]. However this is utterly complex to implement. [1] http://www.nongnu.org/libunwind/man/libunwind

Re: elfutils/libdw ARM compilation (native and cross compile)

2014-02-26 Thread Jean Pihet
Hi Mark, On 26 February 2014 00:26, Mark Wielaard wrote: > Hi Jean, > > Seems you already got your answer to the build question solved. Yes! There is quite a huge improvement in performance: >500% for dwarf unwinding ;-p > > On Tue, 2014-02-25 at 18:17 +0100, Jean Pihet wrote: >> The goal is to