Re: .eh_frame, .eh_frame_hdr - how to remove that trash

2011-10-21 Thread Wojciech Puchar
on entry into each function, which is different from usual x86 convention. Asynchronous unwind info (yeah, same stuff you keep referring to as crap), is the only way you can debug your program or get anything remotely close to usable backtrace, by default. i understand but i DO NOT called compil

Re: .eh_frame, .eh_frame_hdr - how to remove that trash

2011-10-21 Thread Garrett Cooper
On Fri, Oct 21, 2011 at 12:51 AM, Wojciech Puchar wrote: >> on entry into each function, which is different from usual x86 >> convention. >> Asynchronous unwind info (yeah, same stuff you keep referring to as >> crap), is the only way you can debug your program or get anything >> remotely close to

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Razmig K
Le 20.10.2011 19:57, Razmig K a écrit : the memory footprint in C/C++ code for a program running under FreeBSD and Linux in terms of total process size including heap objects Well getrusage does actually exist in Linux, but its behaviour isn't the same as on FreeBSD; struct rusage memory u

Re: .eh_frame, .eh_frame_hdr - how to remove that trash

2011-10-21 Thread Wojciech Puchar
that i do not want to debug isn't it? It seems like a binutils bug (or somewhere in that immediate neighborhood) because all debugging related sections should be stripped out by strip including unwind, correct? indeed. ___ freebsd-hackers@freebsd.org

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Razmig K
Le 21.10.2011 10:44, Peter Jeremy a écrit : On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: It's not clear whether the program is attempting to determine it's own (or a child's) memory footprint, or that of an arbitrary process. In the former case, getrusage() is the obvious choice. This as a po

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Ivan Voras
On 21/10/2011 12:19, Razmig K wrote: > Le 21.10.2011 10:44, Peter Jeremy a écrit : >> On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: >> It's not clear whether the program is attempting to determine it's >> own (or a child's) memory footprint, or that of an arbitrary process. >> In the former case,

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Razmig K
Le 21.10.2011 12:26, Ivan Voras a écrit : Well, do you know that SIZE in top is virtual memory size, not resident size (which is the "RES" column)? You can allocate whatever you want from virtual memory, it is not "used" until it's touched. Yes, I do. So do you suggest using RES as a better ind

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Peter Jeremy
On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: > I'd like to measure the memory footprint in C/C++ code for a >program running under FreeBSD and Linux in terms of total process size >including heap objects. Due to execution length, I'd like to avoid the >use of valgrind. It's not clear whe

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Ivan Voras
On 21/10/2011 12:57, Razmig K wrote: > Le 21.10.2011 12:26, Ivan Voras a écrit : >> Well, do you know that SIZE in top is virtual memory size, not resident >> size (which is the "RES" column)? You can allocate whatever you want >> from virtual memory, it is not "used" until it's touched. > > Yes,

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Wojciech Puchar
footprint? Almost certainly yes. Measuring virtual memory is significantly less important for real-world loads. Some of this is very nicely described here: https://www.varnish-cache.org/trac/wiki/ArchitectNotes . definitely. just run top and compare RES and SIZE fields. extreme example: #inc

Re: Measuring memory footprint in C/C++ code on FreeBSD

2011-10-21 Thread Dan Nelson
In the last episode (Oct 21), Razmig K said: > Le 21.10.2011 10:44, Peter Jeremy a écrit : > > On 2011-Oct-20 19:57:31 +0200, Razmig K wrote: > > It's not clear whether the program is attempting to determine it's own > > (or a child's) memory footprint, or that of an arbitrary process. In > > the

Re: .eh_frame, .eh_frame_hdr - how to remove that trash

2011-10-21 Thread Alexander Kabaev
On Fri, 21 Oct 2011 00:54:32 -0700 Garrett Cooper wrote: > On Fri, Oct 21, 2011 at 12:51 AM, Wojciech Puchar > wrote: > >> on entry into each function, which is different from usual x86 > >> convention. > >> Asynchronous unwind info (yeah, same stuff you keep referring to as > >> crap), is the o