> Another thing to note for output-side optimization is that it's common
> to have many entries that are adjacent except for a gap of a few bytes.
> This too is normal and correct as generated. The gaps are alignment bits
> in .text between multiple entry points in a CU. It's correct precision
>
= Work done last week:
* Time spent on elfutils: ~80%
* Fix 10-byte LEB128
* Check that each CU is referenced only from one pub* section
* Match the way dwarflint reports offsets with the way elfutils
does it, so that it's easily possible to look up DIEs, CUs, etc. in
rea
Hi,
.debug_arange analysis shows that there's a lot of holes in .text.
Turns out these are NOP runs (for alignment purposes, I guess). First,
is it OK for the producer to leave NOP runs alone? If yes, dwarflint
shouldn't warn about it, but then there is a problem of how to detect this.
I t
Roland McGrath wrote:
But, I tend to think we are starting to bend over too much towards the
buggy producers. Though we haven't investigated it yet, all overlaps sure
seem damn suspect to me.
I pushed .debug_ranges and .debug_loc validation today, and both of
these report /huge/ amounts of ov
Roland McGrath wrote:
.debug_arange analysis shows that there's a lot of holes in .text.
Turns out these are NOP runs (for alignment purposes, I guess). First,
is it OK for the producer to leave NOP runs alone? If yes, dwarflint
shouldn't warn about it, but then there is a problem of how to d
Roland McGrath wrote:
* Check that each rangelistptr is aligned to CU's address_size
This is canonical but not actually mandatory.
It's a message with impact 4. If it's not a big deal, I'll make it 2
(i.e. harmless, but suspicious).
- DW_OP_bra and DW_OP_skip: that they don'
Roland McGrath wrote:
* Split into C and C++ part. Eventually, I may get around to
C++-ify all the C-only GNUisms I've sprinkled across dwaflint, but right
now having two "halves" (high-level C++, low-level C) makes more sense.
Agreed. (I did a quick attempt at compiling dwarflint.c as
= Work done last week:
* Time spent on elfutils: ~80%
* Tweaks and small fixes, improving the logic in places.
* First high-level check: ranges/aranges mismatch
* Checking ranges in .debug_ranges and .debug_loc: that there is
a section for the range, the the range does
The date should have been 2009-02-10, not 2009-02-02.
signature.asc
Description: OpenPGP digital signature
___
elfutils-devel mailing list
elfutils-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/elfutils-devel
Roland McGrath wrote:
* Or maybe do a bit of C++ification.
Don't put any priority on this
unless you decide some code is better done using C++ containers than ad hoc
in C or something specifically useful like that.
That's the reason I would be doing it.
PM
signature.asc
Description
Hi,
I'm wondering about how to determine if the address pair read from
loclist is terminating the sequence. When no relocations are in effect,
that's easy: (0,0) is the terminal. But with relocations? Currently
it's considered a terminal if it's (0,0), and neither of the two
addresses was
= Work done last week:
* Time spent on elfutils: ~80%
* Relocations. Checking .debug_info, .debug_loc, .debug_ranges.
Went through the "dwarflint relocs" e-mail that Roland posted a month
ago, and everything that he mentioned should be implemented.
** Relocations are
Petr Machata wrote:
= Work scheduled for this week:
* Expected time spent on elfutils: 50-80%.
* Relocations of .debug_pub*, .debug_aranges.
* Low-level checking of .debug_line.
signature.asc
Description: OpenPGP digital signature
Roland McGrath wrote:
* With a bit of luck, I may get around to start hacking on
expected-trees high level check. (Planning this arbitrarily, because
Mark Wielaard asked me about the low-pc-less DW_TAG_label last week.)
Ok. A place to start is a table based on Appendix A. For each ta
Roland McGrath wrote:
I put some time into that over the week. The code now includes maps of
expected attributes (per DIE tag), and expected forms (per attribute form).
You should not need the latter, at least not done in that way. The
dwarf::location_attr interfaces already encode that knowl
= Work done last _two_ weeks:
* Time spent on elfutils: ~50%
* Bugfixes and improvements in relocation handling
** Warn if some place seems to lack a relocation
** Handle relocations in .debug_pub*, .debug_aranges
** Operate properly in absence of re
Sharyathi Nagesh wrote:
Since I was not able to find a good documentation I was not able to
validate the code design. If some one can review and provide me guidance
it will help me immensely.
Challenges are
a. Efficient way of accessing the function/subprogram DIE (Debug
Information
Sharyathi Nagesh wrote:
I looked into libdwfl.h, which is used by systemtap, as I understand
this will be useful in debugging running machine and not the case I
am looking for so I am considering only libdw.h for the time being.
libdwfl can be useful also for post-mortem debugging. It manages
= Work done last _two_ weeks:
* Time spent on elfutils: ~40%
* Validate DW_AT_stmt_list and record references to .debug_line.
Check .debug_info->.debug_line references.
* Improve error messages and error message handling and filtering.
* Bugfixes
= Work scheduled next:
*
= Work done last week:
* Time spent on elfutils: ~80%
* Mass testing. My debuginfo tree got somehow screwed up, and the
test failed on file-not-found errors quite often. Some files that were
supposed to be .debug.bz2 were plain .debug. Eventually got fed up with
having to manuall
the callback. Etc.
Patch attached.
PM
From 3e9c7e605e666ef32d193f9d303ebd801e67 Mon Sep 17 00:00:00 2001
From: Petr Machata
Date: Tue, 24 Mar 2009 15:04:53 +0100
Subject: [PATCH] : Don't swallow last attribute
---
libdw/ChangeLog |5 +
libdw/c++/dwarf | 11 ---
2 files
Roland McGrath wrote:
As a fix for that, I propose to consider also NULL-ness of _m_attr.value
when doing the iterator comparison.
I think you can just do valp == valp comparison and drop the offset
comparison. The pointers will match when the offsets match, and two NULLs
are two end iterato
Roland McGrath wrote:
The changes that you requested, and the testcase, are on pmachata/dwarf.
Thanks.
@@ -637,7 +637,7 @@ namespace elfutils
inline attribute operator* () const
{
- if (unlikely (_m_offset == 1))
+ if (unlikely (_m_offset == 1 && _m_attr.valp ==
Roland McGrath wrote:
We do, that's the new end iterator condition. offset==1 valp!=NULL is
valid iterator pointing to the last element.
But valp==NULL is never a valid non-end iterator.
Ah, I didn't notice you talk about offset. Right, we don't need offset
check.
PM
signature.asc
Des
Petr Machata wrote:
Roland McGrath wrote:
We do, that's the new end iterator condition. offset==1 valp!=NULL
is valid iterator pointing to the last element.
But valp==NULL is never a valid non-end iterator.
Ah, I didn't notice you talk about offset. Right, we don't nee
Hi,
I'm getting a couple cases where a relocation of DW_AT_low_pc and
DW_AT_high_pc attribute is formed against a section that's either
non-EXEC, or even non-ALLOC.
The case of non-EXEC is in .rodata of vmlinux. A single die that comes
from arch/x86/kernel/trampoline_32.S has this property.
Roland McGrath wrote:
The case of non-EXEC is in .rodata of vmlinux. A single die that comes
from arch/x86/kernel/trampoline_32.S has this property. So I shift my
understanding of low_pc and high_pc from "we can expect PC to have this
address" to "it's a place in address space".
I looked at
Hi,
In this file:
kernel-debuginfo-2.6.29-0.258.rc8.git2.fc11.i586:usr:lib:debug:lib:modules:2.6.29-0.258.rc8.git2.fc11.i586:vmlinux
I'm seeing relocations that seem wrong: the addend and the value of the
symbol the relocation is done against are the same.
Relocation section [71] '.rel.debug_
Roland McGrath wrote:
In this file:
kernel-debuginfo-2.6.29-0.258.rc8.git2.fc11.i586:usr:lib:debug:lib:modules:2.6.29-0.258.rc8.git2.fc11.i586:vmlinux
This is not an ET_REL file. It's a final link that uses --emit-relocs.
The DWARF data (and all the rest) is fully relocated already.
The ke
= Work done last couple weeks:
* Time spent on elfutils: ~50%, had some RHEL & Fedora-related work to
do.
* Done rough testing, where I just wanted to swipe over all files and
was filtering out messages using several broad regexes. Doing more
elaborate testing now. The rejection ru
Roland McGrath wrote:
In the meantime, I think the new thing for you to work on this week is the
"smart reader" hooks (now DwarfTasks 4.2). That does not have other
prerequisites from me holding it up. It should naturally mix in well with
the tail end of the dwarflint reloc work, as that is use
Petr Machata wrote:
Will commit something later today
Done that now. It's on pmachata/reader_hooks branch, forked off master.
These "hooks" are currently simple global functions. When you say
"hook", I get the idea of a client- or generally external-party-sup
Use const pointers everywhere.
That was the original plan, but you can't assign char** to char const**
under C typing. I decided it's better to just keep them char** to avoid
having to either type cast the pointers in function arguments, or having
to rewrite surrounding typing.
Two of the
Roland McGrath wrote:
* What is read_length for? I don't think there can be any relocs in the
DW_FORM_block* length fields. What other use do you envision for it?
Probably nothing. I rolled it in when I've hit some length-related
code, having remembered that you've mentioned length in one
Roland McGrath wrote:
* dwarf_formudata needs special treatment.
This is now on the branch. The new function is called
__libdw_read_udata_address. There's a mismatch between what the
function does and what the code in dwarf_ranges looks like, I need to
look that some more tomorrow.
Doing
Roland McGrath wrote:
Roland McGrath wrote:
* dwarf_formudata needs special treatment.
This is now on the branch. The new function is called
__libdw_read_udata_address.
"address" does not make sense here--it's an offset that's being relocated.
It should use the read_offset hook internally.
Roland McGrath wrote:
__libdw_read_begin_end_pair_inc inverts the return value check on
READ_AND_RELOCATE, no? Since that's the only place that looks at
the value of the expression, just make its value a "was relocated"
Boolean (i.e. "status > 1").
Right, there was a bug there.
I think we ca
Roland McGrath wrote:
Are you about ready to move on to the testing regime?
I'm ready when you are.
Ok! Am I ready? :-) What kind of ready should I be?
Is the plan I explained clear? (Did I explain it?)
The first stage is to do the testing hacks and verify
on the build's own .o files. Afte
Roland McGrath wrote:
You explained it well enough for me to get on with the testing. I
though you have something more on mind, is why I used that phrase. If
not, I'll proceed.
In mind? Me? In what mind?!?
Hard to say, since you seem to be out of the same last two messages :)
PM
signat
Doing the above, I found myself looking at dwarf_getmacros. The way
offsets are handled in this functions strikes me as wrong: macoff is
read from attribute, and then never used; [...]
Yes, it's wrong. It was never noticed since this was so little used or
tested, and it always happens to work
I've launched debug_info test at the end of the last week. I modified
dwarflint & libdw to print out every memory location considered for
relocation. The test itself then is to use readelf -winfo and dwarflint
to collect reloc prints, and expect them to be the same.
The test takes ages. I h
Roland McGrath пишет:
Please merge master into your branch so diff master..pmachata/reader_hooks
looks pure.
Done.
PM
signature.asc
Description: OpenPGP digital signature
___
elfutils-devel mailing list
elfutils-devel@lists.fedorahosted.org
https:
Roland McGrath wrote:
There are an awful lot of nested function calls. Although they are
marked inline, are we sure gcc sees through that?
I don't think we have looked (probably not even tried an -O2 build).
When I pass no CFLAGS to configure, -O2 gets picked by default.
Petr, can you eyeb
Ulrich Drepper wrote:
Petr Machata wrote:
On x86_64, -O1 through -O3, overall change in .text is 2%. Sizes of
particular functions change thus on -O2:
[...]
Did you add something to the hook functions similar to what will be
there later on? I.e., as Roland said
if (SOMETHING
I reorganized the code a bit more, trying not to really sacrifice
readability and other qualities. Now (with fancy_business dummies in
place, these are obviously not committed), the code size changes thus on
x86_64:
dwarf_formaddr 126 263 +1372.09
dwarf_formref_di
Roland McGrath wrote:
To be fair, don't these now do some valid-offset checks that we didn't have
before (and had XXX comments instead)? So that 1-2% is not doing nothing.
Yes, true. Still the fact is that the binary overhead could be cut from
almost 3% to straight 2% with a couple of source
Roland McGrath wrote:
My sense of the priority order of our tasks at large granularity is this:
1. basic writer data structure building (designed for the eventual fancy plans)
What are these "fancy plans"? DWARF compression (as in zlib) was
mentioned a couple times, so that might be one (alt
Roland McGrath wrote:
My new plan is to post this by midnight Sunday my time, which is 9am
Monday CET. (That means I'll post on Friday if I'm not expecting to
do any work on the weekend.) This should let Petr see what my state
is from the previous week/weekend as soon as he starts on Monday.
I'
Hi,
I was experimenting with creating a dwarf file from scrach using
dwarf_edit, but gut stuck when I was unable to figure out how to add an
attribute to a die. So is that a use case that we don't care about, or
are the bits here and I just fail to see them?
Snippet:
dwarf_edit tst;
dw
Roland McGrath wrote:
Also, still getting a lot of:
error: .debug_aranges: addresses 0x412fe9..0x412fe9 of section .text are not
covered.
Is that saying a 0-byte range or a 1-byte range? Perhaps use [x,y] or
[x,y) notation for all byte/addr ranges to be more clear. If it's a 1-byte
range, it
Roland McGrath wrote:
I instantly fell down on my own reporting schedule, of course.
Not a problem, Monday was holiday around here.
Last week:
- Time actually spent on elfutils: 50%
Mostly reading Roland's sources and poking in dwarflint. I expect more
of the latter this week. I hope to re
03.07.2009 21:53, Roland McGrath wrote:
>> That should be 1-byte range. I've introduced the [,) notation, it's on
>> the branch. The alignment is now also considered.
>
> Thanks, this looks much better. I assume that these "section coverage"
> checks are only for inside the ranges covered by som
08.07.2009 21:47, Roland McGrath wrote:
>> It checks all EXECINSTR | ALLOC sections for coverage.
>> If you point me to crt1.o with debuginfo, I can see if it works, and fix
>> it accordingly, but those that I can get my hands on are debuginfo-less.
>
> One of us is confused (or both!). I mentione
Last week
-
Time spent on elfutils: 50%
That was mostly dwarflint. I started work on arange coverage analysis
done only on CU-covered portions of address space.
To decide whether uncovered portion is acceptable alignment, I need to
reintroduce sections into the coverage analysis, beca
20.07.2009 09:11, Roland McGrath wrote:
> Last week:
Time actually spent on elfutils: 50%
Fix bogus messages and exclude some genuine but too common messages from
--gnu, so that dwarflint passes self-test.
Rewrite pieces of low-level to not depend on libdw. Some sort of
validation is therefor
Last week
-
Time spent on elfutils: 80%
* That was mostly output. The approach to handling physical Elf file is
to take the original Elf file, drop all the debug sections, and
reintroduce them rebuilt.
** I took the stripping code from strip.c, made it more C++-y (e.g.
dropped inli
Hi,
pmachata/pending has a patchlet that replaces the use of nl_langinfo in
formatting of DW_FORM_flag with gettext. nl_langinfo gives me empty
string for YESSTR and NOSTR values, which indicates invalid values (per
man page). readelf already uses gettext to format yes/no in case of
has_chil
Last week
-
Time spent on elfutils: 80%
That was all output (well except that readelf locale bit). We emit a
copy of DIE tree since the end of last week.
* References are all broken, DIE offset() is emitted directly instead
of being translated to DIE reference.
* All strings are in
04.08.2009 16:29, Petr Machata wrote:
> My plan for the rest of this week:
>* emit references correctly
About that. While working on that, I've found some memory-related
errors in dwarf_output. pmachata/dwarf-writer has code that works (for
single CU at least), but I had to
A patch implementing $SUBJ is sitting on pmachata/pending. So there are
now two patches, the other one being the locale bit. I don't know how
hard it is to cherry-pick single commit and merge it, shall I create a
separate branch for each issue next time?
PM
___
06.08.2009 19:19, Ulrich Drepper wrote:
> The locale change really shouldn't be necessary. If you see the need
> fix the locale instead.
The thing is that it returns empty string even for LANG=C. In libc,
localedata/locales/POSIX and most of localedata/locales/en_* don't
define "yesstr" and "n
Last week
-
Time spent on elfutils: one sick day, otherwise 80%
Work on output.
* References are emitted correctly.
* All strings are emitted into .debug_str
* DIEs with children and sibling have DW_AT_sibling
* Re-usable bits for back-patching
* dwarflint fixes
Writer wor
11.08.2009 12:28, Petr Machata wrote:
> My plan for the rest of this week:
> * Fix emitting of multi-CU DWARFs. I suspect it's broken, because we
> emit some references section-relative istead of CU-relative.
And it was. First, CUs that didn't fit in one Elf_Data chunk
20.08.2009 11:13, Roland McGrath wrote:
> I've finally merged my output ref/tracker work, though it still has
> issues. I did a squash commit from my old branch, which is now stale.
That's "7cbb50 dwarf_output construction revamp for ref handling", on
dwarf branch, right? I'll work on merging d
Last 2 weeks
Time spent on elfutils: 60-70%
Work on output.
* Small fixes etc.
* Output of VS_constant blocks
* Allow recomputation of back-patches. Used to emit correct
CU-local references, the recomputation being a simple subtraction of CU
offset from the patch value
26.08.2009 07:17, Roland McGrath wrote:
> As I said before, please do not spend any time on the partial_unit issue.
> Just deal with optimal form selection for attribute values.
OK.
> The only class where duplicate values affects the globally optimal choice
> is string. Don't bother trying to th
26.08.2009 20:06, Roland McGrath wrote:
> There must have been something botched in your checkout. Commit a24b207 is
> fine.
The following is from clean clone, clean checkout of origin/dwarf (which
apparently resolves to a24b207, as the helpful git/bash integration
shows). I've done the config
Last week
-
Time spent on elfutils: 70%
Work on output.
* Drop DWARF4 bits that I've had in before for experimenting (e.g.
DW_FORM_flag_present, to check that the optimal form selection works for
extreme cases).
* Emit short strings inline. All strings that are shorter than t
Hi,
for strings of the right size just below the pagesize, not enough memory
was allocated, and malloc internals got corrupted, eventually leading to:
$ ./src/writer ./src/dwarflint
*** glibc detected *** ./src/writer: malloc(): memory corruption:
0x13d3e860 ***
Reproducer (run through
Hi,
I was looking at commits to master branch of elfutils. Just below HEAD,
we have two commits related to Spanish translation, both of which are
suspicious.
b70263b0a78ac5d98b382932c8506a2f58c11963 simply removes some
translations. This may actually be legitimate, perhaps they were wrong,
I stumbled upon one more case of an apparently wrong translation:
po/it.po in elfutils project in fact localizes strings from some sort of
Fedora/Python integration package. (For members of fedora-trans...@r.c,
the previous case was Spanish.)
So it seems to be common mishap that someone someho
07.09.2009 20:51, Roland McGrath wrote:
> It may be appropriate to ask rather than the
> individual translation teams.
I've done that.
PM
___
elfutils-devel mailing list
elfutils-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/el
Last 3 weeks
Time spent on elfutils: ~50%
I had a couple days off, is the reason it's so low.
dwarflint:
* Check address size against the bit-ness of the ELF
* Always emit error about missing DW_LNE_end_sequence
* Fix messages: sibling mismatch reports offset of the right DIE; when
I wonder about the following:
$ src/dwarfcmp ./a.out ./a.out.out
3d vs 57: data_member_location={locexpr} vs
data_member_location={loclist 1 entries}
It's certainly not optimal to store it this way, but aren't these two
cases actually equal? (Um, assuming there's no other difference, like
the
25.09.2009 19:47, Petr Machata wrote:
> I wonder about the following:
>
> $ src/dwarfcmp ./a.out ./a.out.out
> 3d vs 57: data_member_location={locexpr} vs
> data_member_location={loclist 1 entries}
>
> It's certainly not optimal to store it this way, but aren't t
25.09.2009 20:51, Roland McGrath wrote:
>> $ src/dwarfcmp ./a.out ./a.out.out
>> 3d vs 57: data_member_location={locexpr} vs
>> data_member_location={loclist 1 entries}
>>
>> It's certainly not optimal to store it this way, but aren't these two
>> cases actually equal? (Um, assuming there's no oth
25.09.2009 21:13, Roland McGrath wrote:
After a conversation with Jan Kratochvil: a.out.out is what the writer
makes from a.out. The one loclist range is defined over 0..0x...,
because it came up from the locexpr block.
So it uses DW_FORM_sec_offset, then? (Otherwise the reader should hav
Last week + today
-
Time spent on elfutils: ~50%
writer:
* Emit .debug_ranges
* Emit .debug_loc
* dwarfcmp ./a.out ./a.out.out now works
It's on pmachata/dwarf-writer.
Next in plan
* Merge in dwarf branch.
* Make dwarfcmp work for bigger files.
* We can't optimiz
29.09.2009 17:00, Petr Machata wrote:
> * Merge in dwarf branch.
The dwarf branch seems broken. The dwarfcmp tests all fail (sigabrt,
sigsegv). Roland, is that anything that you know about? I'll postpone
my merge for a bit.
PM
___
elfuti
30.09.2009 09:31, Roland McGrath wrote:
> The location/ranges fixes I did the other day uncovered an old braino in
> dwarf::attr_value::what_space. I fixed that, and the dwarfcmp-self tests
> pass again. The dwarfcmp-test (i.e. dwarf_output) cases are still crashing
> but I'm not going to touch t
Hi,
I'm implementing a check that the range of .debug_loc addresses doesn't
run off range claimed by DW_AT_low_pc/high_pc pair or DW_AT_ranges. It
just so happens that it's also easy to check that ranges of a DIE are
sub-range of its parent, since I need that range-tracking logic anyway.
Su
I've implemented the test for $SUBJ, and am running into lots of
violations that look genuine. Current criteria are: for each attribute
with loclist value (i.e. VS_location, .is_list holds) check that the
address ranges of that location list form a subset of PC ranges of
containing PC-ful DIE.
06.10.2009 08:44, Roland McGrath wrote:
> These:
> inlined_subroutine
> lexical_block
> entry_point
> label
> with_stmt
> try_block
> catch_block
> can have PC's and those should be entirely inside the containing PC-ful
> entry.
Thanks. I've implemented i
06.10.2009 22:47, Roland McGrath wrote:
> error: .debug_info: DIE 0x13c1: attribute `location': PC range [0x4014a6,
> 0x401561) outside containing scope
> error: .debug_info: DIE 0x13bc: in this context: [4013d4, 40155a), [4018c0,
> 4018cf), [401db6, 401e03)
>
> Except please make all the address
05.11.2009 20:44, Roland McGrath wrote:
>> The problem seems to be that l_name, l_ld and l_addr loaded from the
>> dump in report_r_debug all end up being zero.
>
> Ok. I made it check for 0 and just ignore such entries.
>
>> With l_ld of 0 we find nothing, dwfl_addrsegment returns -1, and
>> repo
05.11.2009 16:41, Petr Machata wrote:
> P.S. Jiri (CCd) mentioned to me on the IRC that he suspects Abrt
> core-handling hook might have mangled the dump. The above happens for
> the last module in the dump, so one possibility to look into is that the
> dump gets truncated. I'
11.11.2009 16:37, Petr Machata wrote:
> 05.11.2009 16:41, Petr Machata wrote:
> But I think there is a bug in libdwfl, the library shouldn't find zeroes
> there.
The bug is in read-ahead logic of dwfl_elf_phdr_memory_callback. It
reads ahead as much of offset-contiguous data
12.11.2009 22:37, Roland McGrath wrote:
>> The bug is in read-ahead logic of dwfl_elf_phdr_memory_callback. It
>> reads ahead as much of offset-contiguous data as it can, but doesn't
>> take into account whether the data is vaddr-contiguous too.
>> report_r_debug assumes it is.
>
> I am confused.
30.09.2009 12:42, Petr Machata wrote:
> 30.09.2009 09:31, Roland McGrath wrote:
>> The dwarfcmp-test (i.e. dwarf_output) cases are still crashing
>> but I'm not going to touch that in hopes I can just replace that mess soon
>> enough with the new code I've been wo
05.01.2010 04:47, Roland McGrath wrote:
> The others I think are positively fixed. I put a bug in ASSIGNED state (vs
> NEW) when I think it's covered by something already in elfutils.git.
> (Perhaps I should use MODIFIED, but that is meant for when there is an rpm
> built I think.)
Isn't MODIFIED
17.02.2010 12:01, Roland McGrath wrote:
> Petr, please review the libdwfl change (and this explanation) and verify
> that it makes sense.
The patch seems correct to me. And thanks for the clear explanation,
that's appreciated.
PM
signature.asc
Description: OpenPGP digital signature
__
Is there a plan to publish the symbol dwfl_core_file_report? It's
currently used for unstrip --core. Right now Abtr folks are running
unstrip and parsing its output to get their hands on the build IDs, but
would like to be able to use API instead.
For the reference, the API already exposes the c
11.03.2010 08:39, Roland McGrath wrote:
> Since they spawn eu-unstrip, our core-grokking bugs have been making
> eu-unstrip crash when abrtd runs it. This leads to abrtd catching that
> secondary crash, and filing bugs on elfutils. So that means we've been
> chasing these bugs ourselves when we s
... sits on the branch "pmachata/576283", commits b6b942 and 3fdd54
(testcase and fix).
The problem appears ta be that the backlink from data to section,
data.s, is not initialized for bitless sections (NODATA or zero size).
The link should be initialized in convert_data, but that's not called
for
06.04.2010 08:52, Roland McGrath wrote:
> We don't have any other tests named for bug numbers, so let's not start
> that now. Give it a meaningful name like bug-flagdata-nobits.
>
> +int
> +main (__attribute__ ((unused)) int argc,
> + __attribute__ ((unused)) char **argv)
>
> main can just
Mark Wielaard 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)
> +
- 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
---
libdw/ChangeLog | 7 +
libdw/dwarf_ranges.c
Roland McGrath writes:
> That looks OK to me, but the #include seems extraneous.
It's a leftover from debugging printfs, that I forgot to remove.
I removed it now and pushed.
Thanks,
Petr
Josh Stone 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 to me. I don
Josh Stone 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 case.
GCC is
1 - 100 of 303 matches
Mail list logo
