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
called libdwpp with versioned
symbols.
Signed-off-by: Petr Machata pmach...@redhat.com
---
ChangeLog | 4 +
NEWS| 5 +-
libdw/ChangeLog | 21
libdw/Makefile.am | 62 -
libdw/c
- Detect C++ compiler in configure, add supporting infrastructure to
eu.am.
Signed-off-by: Petr Machata pmach...@redhat.com
---
ChangeLog| 4
config/ChangeLog | 6 ++
config/eu.am | 21 -
configure.ac | 15 +++
4 files changed, 45
Mark Wielaard m...@redhat.com writes:
OK, with those changes.
Pushed with those changes.
Thanks,
Petr
I see this wouldn't apply cleanly anymore, due to recent x32 patches. I
put the code on the branch pmachata/iterators, for those interested.
Thanks,
Petr
Mark Wielaard m...@redhat.com writes:
On Fri, 2015-04-03 at 10:28 +0200, Petr Machata wrote:
- Detect C++ compiler in configure, add supporting infrastructure to
eu.am.
Looks good. Two questions below, but not blockers. Just curious.
index faf8add..f1d290b 100644
--- a/config/eu.am
Petr Machata pmach...@redhat.com writes:
I am happy we have an explicit ABI now. But I am somewhat concerned
about how libdw/libdwpp.map looks. Is this really the best we can do? It
feels somewhat unmaintainable if we have to hand edit this version
script. How did you generate
Mark Wielaard m...@redhat.com writes:
I like this because it makes things easy and clear on the ABI side.
I am not so concerned about the PLT call, but the new allocation and
delete in the destructor is indeed a little heavy-weight since I assume
iterators are often short lived so it will
Jan Heylen heyl...@gmail.com writes:
Ok, I was thinking it would go into this direction. I'm willing to do
the effort for this (as having the right backend installed could be
useful one day indeed), should I even consider looking at the
mjw/RH-DTS branch? Or how do you propose I could tackle
Mark Wielaard m...@redhat.com writes:
On Tue, 2015-03-31 at 17:09 +0200, Petr Machata wrote:
Mark Wielaard m...@redhat.com writes:
And you can match against EM_##ARCH in the per-arch executor to select
the correct one for the ELF you are examining?
You could do something like
Signed-off-by: Petr Machata pmach...@redhat.com
---
libdw/ChangeLog | 9 +
libdw/dwarf_error.c | 3 ++-
libdw/dwarf_getsrcfiles.c | 9 +
libdw/dwarf_getsrclines.c | 11 ++-
libdw/libdwP.h| 7 +++
5 files changed, 29 insertions(+), 10
Mark Wielaard m...@redhat.com writes:
On Fri, 2015-03-27 at 21:32 +0100, Petr Machata wrote:
Mark Wielaard m...@redhat.com writes:
On Wed, 2015-03-18 at 00:55 +0100, Petr Machata wrote:
The iterators are essentially glorified structs. The usual C++ ABI
concerns don't apply (reordering
Mark Wielaard m...@redhat.com writes:
On Mon, 2015-03-30 at 09:40 +0200, Mark Wielaard wrote:
On Sat, 2015-03-28 at 23:41 +0100, Mark Wielaard wrote:
I do like the idea. But there is one extra issue if we want this to be
an installed header like known-dwarf.h now is (and I think we do).
Mark Wielaard m...@redhat.com writes:
I like it. And I was happy to note that we don't even used the _DESC
We did, we just never used the DESC itself, instead simply forwarding to
non-DESC variant. Which probably means it wasn't very useful to begin
with.
variants in our code. Could you add
Mark Wielaard m...@redhat.com writes:
And you can match against EM_##ARCH in the per-arch executor to select
the correct one for the ELF you are examining?
You could do something like this:
#define ELF_ONE_KNOWN_DT_ARCH (ARCH) \
if (ARCH == my_arch) \
{
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
Mark Wielaard m...@redhat.com writes:
On Wed, 2015-03-18 at 00:55 +0100, Petr Machata wrote:
these iterators originated a couple years back on the dwarflint branch.
Back then Roland added some C++ wrappers and we started writing stuff in
C++. I've been lugging them around ever since, first
Pushed.
Thanks,
Petr
Hi there,
dwgrep needs to programmatically work with ELF constants, so I put
together the attached script.
The basic idea is the same as with known-dwarf, but elf.h has some extra
challenges to address:
- It's not entirely predictable which constants are bona fide values,
and which are
Petr Machata pmach...@redhat.com writes:
Forgot to include the following:
And this as well:
diff --git a/tests/Makefile.am b/tests/Makefile.am
index b519679..dc2a946 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -291,7 +291,7 @@ EXTRA_DIST = run-arextract.sh run-arsymtest.sh
.
Signed-off-by: Petr Machata pmach...@redhat.com
---
config/ChangeLog | 7
config/known-dwarf.awk | 13 ++--
libdw/ChangeLog| 5 +++
libdw/Makefile.am | 4 +--
src/ChangeLog | 11 ++
src/readelf.c | 90
Signed-off-by: Petr Machata pmach...@redhat.com
---
tests/ChangeLog | 5 +
tests/Makefile.am | 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/ChangeLog b/tests/ChangeLog
index ae2262b..223fab4 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,5 +1,10
Роман Донченко 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
Forgot to include the following:
diff --git a/ChangeLog b/ChangeLog
index f81b302..35e4deb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2015-03-18 Petr Machata pmach...@redhat.com
+
+ * configure.ac (HAVE_CXX): New conditional.
+ * NEWS: Mention two new header files, c
Роман Донченко 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
Роман Донченко 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
Pushed.
Thanks,
Petr
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
Mark Wielaard m...@redhat.com writes:
On Tue, 2015-03-03 at 13:46 +0100, Petr Machata wrote:
known-dwarf.h is an extremely handy header file. I regularly find
myself replicating it in my ELF/DWARF-related projects. In dwgrep
I simply copy over known-dwarf.awk as such and generate the header
Pushed.
Thanks, Petr
Hi there,
known-dwarf.h is an extremely handy header file. I regularly find
myself replicating it in my ELF/DWARF-related projects. In dwgrep
I simply copy over known-dwarf.awk as such and generate the header
myself.
Obviously that's not ideal. Could known-dwarf.h be shipped? In
dwlocstat I
Alexandre Oliva aol...@redhat.com writes:
Ok, I looked into it further, after patching dwlocstat to dump
per-variable per-range coverage/length info, so as to be able to compare
object files more easily.
If you send me those patches, I can finish them, bind the functionality
to a command line
Jakub Jelinek ja...@redhat.com writes:
it counts on what percentage of bytes in those ranges (or instructions?)
the variable has defined location.
Yes, it counts bytes. It doesn't know anything about instruction
lengths etc.
Thanks,
Petr
Orion Poplawski or...@cora.nwra.com writes:
On 02/24/2015 05:22 PM, Kevin Kofler wrote:
Orion Poplawski wrote:
Getting:
/builddir/build/BUILD/mrpt-1.0.2/libs/base/include/mrpt/utils/mrpt_macros.h:296:150:
error: no match for 'operator' (operand types are
'std::basic_ostreamchar' and
Signed-off-by: Petr Machata pmach...@redhat.com
---
backends/ChangeLog| 5 +
backends/arm_init.c | 3 ++-
backends/arm_symbol.c | 15 ++-
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/backends/ChangeLog b/backends/ChangeLog
index 57e1b8e..9f5975a 100644
Roland McGrath rol...@hack.frob.com writes:
OK except for typo in patch title.
Pushed with that typo fixed.
Thanks,
Petr
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.
Pushed.
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
Signed-off-by: Petr Machata pmach...@redhat.com
---
config/ChangeLog | 5 +
config/known-dwarf.awk | 11 ++-
2 files changed, 7 insertions(+), 9 deletions(-)
mode change 100644 = 100755 config/known-dwarf.awk
diff --git a/config/ChangeLog b/config/ChangeLog
index 1b4e896
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
Josh Boyer jwbo...@fedoraproject.org writes:
We should not include preprocessed source files by default without the user
knowing and agreeing. People use gcc to build proprietary source still.
There's a check box to this effect in ABRT. It's not much different
from sending backtraces or some
- Instead of bailing out at iteration start, we remember the
base-address-selecting attributes were not seen, and then bail out
later if no base address selection entry has been seen.
Signed-off-by: Petr Machata pmach...@redhat.com
---
libdw/ChangeLog | 7 +
libdw
Roland McGrath rol...@hack.frob.com writes:
That looks OK to me, but the #include stdio.h seems extraneous.
It's a leftover from debugging printfs, that I forgot to remove.
I removed it now and pushed.
Thanks,
Petr
Josh Stone jist...@redhat.com writes:
With CFLAGS='-Og -g', F21 gcc hits -Werror=maybe-uninitialized on jmp in
the call prepare_thread (pid2, jmp). It's fine with -O2/-O0.
The only way this could be unset is if the loop before ran to
completion, and there's already an assert against this
Josh Stone jist...@redhat.com writes:
With CFLAGS='-Og -g', F21 gcc hits -Werror=maybe-uninitialized in
read_encoded_value at *result += value. It's fine with -O2/-O0.
By my inspection, the only way those don't set value are for error
cases, which will then return immediately.
Looks good
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
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
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
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 @@
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
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
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
Applied.
Thanks,
Petr
___
Ltrace-devel mailing list
Ltrace-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
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,
Parag Nemade panem...@gmail.com writes:
I actually got more confused when pmachata built harfbuzz without
giving specific information in the changelog.
The reason was that I was rebuilding both Boots and ICU deps, and since
I just took a list of conflicts en blocks (as explained in another
Mikolaj Izdebski mizde...@redhat.com writes:
I don't know why 0.9.38-3 was built, it looks like unnecessary build.
Yes, it is.
About 30 packages diverged after f22-boost side-tag had been created.
It's impractical to check by hand whether any happened to be already
rebuilt in the short window
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;
Hi,
Most of the mass rebuild finished last week already, but due to FOSDEM
and other circumstances (like me leaving the result file on my home NFS
out of reach yesterday) I'm only getting to writing this now. A bunch
of Boost-related bugs have been already resolved, or I contacted the
Dodji Seketeli do...@seketeli.org writes:
but the link just points to the package. While it's not necessarily
difficult to use, I wouldn't quite call it intuitive either.
Indeed. And while we are in the Shameless Plug department, I'd like
to mention the presence of a new tool called
commit 71b6739cd7e4f2863289ba4993ff2e25a68d17d1
Author: Petr Machata pmach...@redhat.com
Date: Mon Jan 26 21:17:28 2015 +0100
Rebuild for boost 1.57.0
slic3r.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/slic3r.spec b/slic3r.spec
index 6f99957
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
Petr Machata pmach...@redhat.com writes:
I'll rebase TBB to 4.3u2 next week.
This is now done in Rawhide. The F21 update is here:
https://admin.fedoraproject.org/updates/tbb-4.3-1.20141204.fc21
Thanks,
Petr
--
devel mailing list
devel@lists.fedoraproject.org
https
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
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
---
Dodji Seketeli do...@seketeli.org writes:
Petr Machata pmach...@redhat.com a écrit:
The soname didn't change. I reviewed the actual changes using abidiff,
and the only thing reported that I think is an actual ABI violation is
insertion of one virtual method. I don't think that's real
The packages with MPICH enabled are here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8678117
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2283793
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1706653
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2852781
Your favorite time of the year, and mine as well, is here!
The plan is to do the rebase next week, maybe on the weekend already.
As usual, I'll request a side tag, build boost, and then work through
the dependent packages. I'll wrap the work on Thursday at the latest
regardless on what state it
Marcin Juszkiewicz mjuszkiew...@redhat.com writes:
W dniu 19.01.2015 o 20:58, Petr Machata pisze:
I'll rebase TBB to 4.3u2 next week. A scratch build is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8665932
Can you do builds on secondary architectures as well? arm-koji
Hello,
I'll rebase TBB to 4.3u2 next week. A scratch build is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8665932
Client packages are as follows, their owners are CC'd.
adobe-source-libraries-0:1.0.43-23.fc22.src
freecad-0:0.14-5.fc22.src
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:
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
This is an automated email from the git hooks/post-receive script.
pmachata-guest pushed a commit to branch master
in repository ltrace.
commit 9ec8643a49c87835426d0b6ed08eceb818bedb61
Author: Petr Machata pmach...@redhat.com
Date: Fri Jan 16 18:34:54 2015 +0100
In Dwarf test case, define
This is an automated email from the git hooks/post-receive script.
pmachata-guest pushed a commit to branch master
in repository ltrace.
commit 28d6400b322ad09706bbb2a09d2ca33eff263e1a
Author: Petr Machata pmach...@redhat.com
Date: Fri Jan 16 18:34:35 2015 +0100
In Dwarf prototype
This is an automated email from the git hooks/post-receive script.
pmachata-guest pushed a commit to branch master
in repository ltrace.
commit 6db31e662a7461c23b76c1de7a488e284d2e8613
Author: Petr Machata pmach...@redhat.com
Date: Fri Jan 16 18:31:56 2015 +0100
Do not add naked voids
Mark Wielaard m...@redhat.com writes:
+ /* Checks the given DIE hasn't been imported yet to prevent cycles. */
+ inline bool imports_contains (Dwarf_Die *die)
+ {
+struct Dwarf_Die_Chain *import = imports;
+while (import != NULL)
+ {
+ if (import-die.addr == die-addr)
This is an automated email from the git hooks/post-receive script.
pmachata-guest pushed a commit to branch master
in repository ltrace.
commit 03983b755083537ccb902c1ad4d9cf41e4790914
Author: Petr Machata pmach...@redhat.com
Date: Wed Jan 7 01:44:50 2015 +0100
Fix for the erase-find
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.
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
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
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
/xtensa/Makefile.am
index ec26162..9ce81e1 100644
--- a/sysdeps/linux-gnu/Makefile.am
+++ b/sysdeps/linux-gnu/xtensa/Makefile.am
@@ -1,6 +1,5 @@
# This file is part of ltrace.
-# Copyright (C) 2014 Petr Machata, Red Hat, Inc.
-# Copyright (C) 2010,2012 Marc Kleine-Budde, Pengutronix
+# Copyright (C
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
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
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
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
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,
I am happy to announce the first release of dwgrep, a tool for querying
Dwarf graphs.
Dwgrep is useful for looking up particular patterns in Dwarf files.
They might be nonsensical or sub-optimal constructs produced as a result
of a compiler bug, rare constructs, or some sort of relationship that
This is an automated email from the git hooks/post-receive script.
pmachata-guest pushed a commit to branch master
in repository ltrace.
commit d80c5371454383e3f9978622e5578cf02af8c44c
Author: Petr Machata pmach...@redhat.com
Date: Tue Dec 9 17:38:56 2014 +0100
Fix cloning
This is an automated email from the git hooks/post-receive script.
pmachata-guest pushed a change to branch master
in repository ltrace.
from fba95ad Initialize the PLT slot map correctly on x86 and x86_64
new d8f1287 Nits
new d80c537 Fix cloning of
.debug_macro, to avoid confusion.
Signed-off-by: Petr Machata pmach...@redhat.com
---
NEWS | 2 -
libdw/ChangeLog| 7 ++
libdw/dwarf_getmacros.c| 157 +++--
libdw/libdw.h | 40 ++-
tests
Josh Stone jist...@redhat.com writes:
I'll see if I can grab that old kernel debuginfo to do a more direct
comparison.
You could grab the old code and compare that. If you're still in the
80's, it's the data, not the code.
Thanks,
Petr
pointer difference. But
passing address size in a 4-byte type is overly generous, so revert
back to uint8_t, like what CU's actually store.
Signed-off-by: Petr Machata pmach...@redhat.com
---
libdw/ChangeLog | 7 +++
libdw/dwarf_getsrclines.c | 6 +++---
libdw/libdwP.h
Petr Machata pmach...@redhat.com writes:
Hanno Böck ha...@hboeck.de writes:
I can't build elfutils git head with -m32 right now at all (likely
another bug? was possible a few days ago), so I can't test, but we can
probably assume that it was due to the systemwide libs it used.
That would
Mark Wielaard m...@redhat.com writes:
Lets get your patch in first. I liked the changes you made. Please
squash those follow up commits before pushing to master. We shouldn't
Merged.
do a release with this new interface before hearing back from the
DWARF committee though. So maybe just add
Mark Wielaard m...@redhat.com writes:
Is it clear what the intent of the function is?
Yes.
And when we do extend the tags that get peeled, do we need to update
the function symbol version?
I don't think so. If we are adding new tags (i.e. from a new Dwarf
version) and the additions fit
--8
Hi there,
I forgot to add these files to the main .debug_macro support patch. I
present them separately here, as I think that will make review actually
easier. But do tell me otherwise. I would of course squash them before
pushing
I'll just post snippets of updated code inline. The full code is on the
branch. Since we are discussing relatively minor points, it seems more
effective this way.
Mark Wielaard m...@redhat.com writes:
I do like to wait a little till the DWARF committee comments on your
request to reserve the
Vicente Olivert Riera vincent.ri...@imgtec.com writes:
I'm having a failure when doing a static build of elfutils because it
tries to build a shared library (.so). Could it be possible to add a
configure option to disable the shared library so only the static one
(.a) would be built?
Note
Mark Wielaard m...@redhat.com writes:
So, assuming we can use the long int padding field as Dwarf_Die pointer,
In other words, do we want to keep backward compatibility on LLP64
architectures? I know Widnows do use this model, do we care? Any
Unices with this model out there? FWIW, x32 and
Pushed.
Mark Wielaard m...@redhat.com writes:
On Tue, 2014-09-30 at 18:06 +0200, Petr Machata wrote:
extern int dwarf_macro_srcfiles (Dwarf_Macro *macro, Dwarf_Files **files,
size_t *nfiles)
Yeah, this interface is nicer than trying to describe the file entry
601 - 700 of 1131 matches
Mail list logo
