This way we don't have to evaluate the 'n' argument twice. We now need
to link libeu.a into some tests, though. The system.h include was
accidentally dropped from elfcompress.c and findtextrel.c, but is
actually necessary when mempcpy is only available from libeu.
Signed-off-by: Ulf Hermann
---
Link them all with -z,defs,-z,relro,--no-undefined, provide complete
dependencies for the link steps, and add libeu.a to each one. libeu.a
contains useful library functionality that each of them might use. The
linker will strip unneeded symbols, so linking it in won't hurt even if
none of the funct
https://sourceware.org/bugzilla/show_bug.cgi?id=21174
--- Comment #7 from Thommy Jakobsson ---
Created attachment 9834
--> https://sourceware.org/bugzilla/attachment.cgi?id=9834&action=edit
Add debug printouts in the perf stack unwind
--
You are receiving this mail because:
You are on the CC
https://sourceware.org/bugzilla/show_bug.cgi?id=21174
--- Comment #6 from Thommy Jakobsson ---
Hi again and thanks for spending the time.
>>Maybe you can debug by triggering the pr_debug ()
Switched the pr_debug to a normal printf, and also added a printout of program
counter directly in the lib
Link them all with -z,defs,-z,relro,--no-undefined, provide complete
dependencies for the link steps, and add libeu.a to each one. libeu.a
contains useful library functionality that each of them might use. The
linker will strip unneeded symbols, so linking it in won't hurt even if
none of the funct
> But like said before argp is needed for the tools and the libdw
> interface. If your glibc replacement doesn't provide argp the build
> should pick up libargp and get the definitions and implementation from
> there.
libdw only needs it for argument parsing, which we can disable if argp isn't
a
> If at all possible I would like elfutils to not turn into some
> abstraction layer for broken non-GNU/Linux systems. I don't mind small
> (mostly) obvious correct defines/checks or tweaks to help out people
> using such broken systems. But if we need a lot more of these things I
> think we shoul
On Thu, 2017-02-16 at 12:32 +0100, Ulf Hermann wrote:
> Rename version.c so that the implementation is called after the header
> and the header doesn't clash with the toplevel version.h. print_version
> depends on argp and is only used in the tools.
Applied, because the split itself is fine.
But
On Fri, 2017-02-17 at 10:50 +0100, Ulf Hermann wrote:
> True. With other missing functions I tend to conditionally build the
> replacements into libeu.a as actual functions. That requires libeu.a
> to be linked into libdw.so, libelf.so, etc. I will create a followup
> patch that does the same with
https://sourceware.org/bugzilla/show_bug.cgi?id=21174
--- Comment #5 from Mark Wielaard ---
(In reply to Thommy Jakobsson from comment #3)
> (In reply to Mark Wielaard from comment #1)
> > How does perf call the libdw getframe function?
> The actual call looks like this
> err = dwfl_getthread_fra
https://sourceware.org/bugzilla/show_bug.cgi?id=21174
--- Comment #4 from Mark Wielaard ---
(In reply to Thommy Jakobsson from comment #2)
> Created attachment 9833 [details]
> disassembly of function IBUFDIST_distribute
That shows the (duplicated) address 6e3628 is the last one before the retur
On 02/17/2017 10:46 AM, Mark Wielaard wrote:
> On Thu, 2017-02-16 at 10:10 +0100, Ulf Hermann wrote:
>> If it doesn't exist, provide a definition based on memcpy.
>
> Applied, but slightly reluctantly. I have no way to test this. And it
> will evaluate the last argument (n) twice. Which seems to n
https://sourceware.org/bugzilla/show_bug.cgi?id=21174
--- Comment #3 from Thommy Jakobsson ---
(In reply to Mark Wielaard from comment #1)
> There is no good way to tell. It could happen if the function calls itself
> (although you would expect the pc to be different).
I did check the assembler
On Thu, 2017-02-16 at 10:10 +0100, Ulf Hermann wrote:
> If it doesn't exist, provide a definition based on memcpy.
Applied, but slightly reluctantly. I have no way to test this. And it
will evaluate the last argument (n) twice. Which seems to not matter in
the current calls in our codebase. But it
https://sourceware.org/bugzilla/show_bug.cgi?id=21174
--- Comment #2 from Thommy Jakobsson ---
Created attachment 9833
--> https://sourceware.org/bugzilla/attachment.cgi?id=9833&action=edit
disassembly of function IBUFDIST_distribute
--
You are receiving this mail because:
You are on the CC l
https://sourceware.org/bugzilla/show_bug.cgi?id=21174
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #1
16 matches
Mail list logo
