On 12/02/2016 01:42 AM, Mark Wielaard wrote:
> Hi,
>
> Someone was porting elfutils libelf to Windows64 and noticed that the
> return types of gelf_newehdr and gelf_newphdr (unsigned long int) is not
> appropriate on that platform. It uses the LLP64 data model where int and
> long are both 32bits,
On 10/26/2016 11:18 AM, Josh Stone wrote:
> On 10/26/2016 10:47 AM, Mark Wielaard wrote:
>> On Wed, Oct 26, 2016 at 09:36:31AM -0700, Josh Stone wrote:
>>> On 10/26/2016 03:24 AM, Mark Wielaard wrote:
>>>> The name used in the standard and other DWARF implementations
On 10/26/2016 10:47 AM, Mark Wielaard wrote:
> On Wed, Oct 26, 2016 at 09:36:31AM -0700, Josh Stone wrote:
>> On 10/26/2016 03:24 AM, Mark Wielaard wrote:
>>> The name used in the standard and other DWARF implementations for
>>> Programming Language One, PL/I, is D
On 10/26/2016 03:24 AM, Mark Wielaard wrote:
> The name used in the standard and other DWARF implementations for
> Programming Language One, PL/I, is DW_LANG_PLI (not DW_LANG_PL1).
>
> Fix usage in dwarf_aggregate_size.
>
> Signed-off-by: Mark Wielaard
> ---
> NEWS | 5 +
On 10/13/2016 03:28 AM, Mark Wielaard wrote:
> On Tue, 2016-10-11 at 23:12 +0900, Akihiko Odaki wrote:
>> unsigned long int is not always capable to have pointer in some cases
>> (LLP64, for example).
>
> This makes sense, but it does change a public API. One we share with
> other libelf implement
On 10/06/2016 07:18 AM, Mark Wielaard wrote:
> Having a symbol in an allocated symbol table (like .dynsym) that
> points to an unallocated section is wrong. Traditionally strip
> has removed such symbols if they are section or group symbols.
> But removing a real symbol from an allocate symbol tabl
On 11/25/2015 08:31 AM, Ben Gamari wrote:
> ---
> src/readelf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/readelf.c b/src/readelf.c
> index 7c3237f..3b6b4a0 100644
> --- a/src/readelf.c
> +++ b/src/readelf.c
> @@ -4973,7 +4973,7 @@ print_cfa_program (const unsig
On 11/25/2015 04:45 AM, Ben Gamari wrote:
> This could have easily saved me three hours.
> ---
> libebl/eblopenbackend.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libebl/eblopenbackend.c b/libebl/eblopenbackend.c
> index b301400..662842d 100644
> --- a/libebl/eblo
On 11/25/2015 08:00 AM, Ben Gamari wrote:
> Previously this was incorrectly assumed to be an ULEB128. Hilarity
> ensued.
Is the error visible in any testcase? Or can you add a test?
> This appears to be the case in both DWARF 3, DWARF 4, and LSB 5.
> ---
> src/readelf.c | 2 +-
> 1 file changed
On 10/09/2015 05:40 PM, Josh Stone wrote:
> Some systems don't have loff_t, like FreeBSD where off_t always supports
> large files. We need a standardized 64-bit signed type for the public
> header, without depending on configuration... OK, just use int64_t.
>
> Signe
On 10/09/2015 06:03 PM, Roland McGrath wrote:
> Let's drop while we're there. Anybody broken by that (unless
> I overlooked some use of such a type in libelf.h itself) deserves to be.
That breaks size_t all over the place, so we at least need stddef.h.
Then Elf_Arhdr breaks 4 more: time_t, uid_
Some systems don't have loff_t, like FreeBSD where off_t always supports
large files. We need a standardized 64-bit signed type for the public
header, without depending on configuration... OK, just use int64_t.
Signed-off-by: Josh Stone
---
libelf/ChangeLog | 4
libelf/libelf.h
On 10/09/2015 02:57 PM, Roland McGrath wrote:
>> However, I'm afraid to change signedness, if only because -1 is used in
>> error conditions, e.g. returned from elf_update(). Someone checking <0
>> will be in for a bad time.
>
> Yeah, that sounds like a wise fear. But maybe Elf64_Off is OK (and
On 10/09/2015 01:57 PM, Roland McGrath wrote:
> Hmm. Is it the case that loff_t or off_t that we want to use will always
> be 64 bits? The way we use it in the libelf interfaces always wants a
> positive offset (or size). I don't think change of signedness really needs
> to count as an ABI chang
On 10/09/2015 01:24 PM, Roland McGrath wrote:
> I really don't like having the big header that we actually hack on be the
> massaged file (not that it's changed often in years, but anyway). Can you
> make the configure-generated thing be just a tiny header that's included
> by libelf.h instead?
S
Some systems don't have loff_t, like FreeBSD where off_t always supports
large files. We can use AC_CHECK_TYPE to support this, with an AC_SUBST
to create a libelf.h specialized for the target system.
Signed-off-by: Josh Stone
---
ChangeLog| 7 +
backends/ChangeLog
On 10/09/2015 04:17 AM, Mark Wielaard wrote:
> On Thu, 2015-10-08 at 13:05 -0700, Josh Stone wrote:
>> AC_SYS_LARGEFILE defines _FILE_OFFSET_BITS in config.h if needed for
>> LFS, and this automatically maps things like open to open64. But quite
>> a few places used explici
to 64-bit variants when _FILE_OFFSET_BITS is set.
Signed-off-by: Josh Stone
---
config/ChangeLog | 4 ++
config/eu.am | 3 ++
libdw/ChangeLog | 5 ++
libdw/dwarf_begin.c | 4 +-
libdwfl/ChangeLog
On 10/06/2015 03:02 PM, Mark Wielaard wrote:
> On Tue, 2015-10-06 at 10:23 -0700, Josh Stone wrote:
>> On 10/06/2015 06:00 AM, Mark Wielaard wrote:
>>> On Mon, 2015-10-05 at 11:15 -0700, Josh Stone wrote:
>>>> Note, elfutils does not explicitly enable AM_SILENT_RU
On 10/06/2015 06:00 AM, Mark Wielaard wrote:
> On Mon, 2015-10-05 at 11:15 -0700, Josh Stone wrote:
>> Note, elfutils does not explicitly enable AM_SILENT_RULES. It's only
>> available starting from automake 1.11
>
> Note that we already require 1.11 or higher for pa
be silent, use "./configure --enable-silent-rules" or "make V=0".
Signed-off-by: Josh Stone
---
backends/ChangeLog | 4
backends/Makefile.am | 4 ++--
config/ChangeLog | 4
config/eu.am | 4 ++--
libasm/ChangeLog | 4
libasm/Makefile.am
On 09/04/2015 10:13 AM, Chih-Hung Hsieh wrote:
> Clang compiler gives warning to non-standard format %Z.
I think the change is fine -- %z is C99 and used in many places.
But isn't Clang rejected by configure.ac for not supporting nested
functions? Are you patching that behavior too?
On 08/20/2015 08:32 AM, Mark Wielaard wrote:
> See Dwarf 4 2.17 Code Addresses and Ranges. In particular elfutils takes
> advantage of:
> "If an entity has no associated machine code, none of these attributes
> are specified."
(A -> B) does not give you (B -> A)!
That is, the spec does *not* say
On 06/30/2015 03:48 AM, Mark Wielaard wrote:
> On Tue, 2015-06-30 at 08:46 +0200, Pino Toscano wrote:
>> while working on the previous patches, I noticed a number of generated
>> files are not part of .gitignore, so git shows them in the status
>> output.
>>
>> Attached there is a patch for it to
On 06/16/2015 02:31 PM, Peter Robinson wrote:
> On Tue, Jun 16, 2015 at 10:26 PM, Dennis Gilmore wrote:
>> On Tuesday, June 16, 2015 02:17:10 PM Mark Wielaard wrote:
>>> On Tue, 2015-06-16 at 00:20 +0200, Mark Wielaard wrote:
Simplest probably is to just revert this one patch and do a elfutil
CC elfutils-devel, this appears to be a regression. I'm top-posting my
own findings, but I'll leave the kernel report below...
With elfutils-0.162, it appears that "strip" doesn't reduce the file
size when operating in-place (without -o). This isn't particular to
funny kernel ELF -- I reproduced
On 05/14/2015 03:44 AM, Mark Wielaard wrote:
> diff --git a/libelf/ChangeLog b/libelf/ChangeLog
> index 2d10b83..5e7b104 100644
> --- a/libelf/ChangeLog
> +++ b/libelf/ChangeLog
> @@ -1,3 +1,8 @@
> +2015-05-14 Mark Wielaard
> +
> + * elf_update.c (write_file): Use possix_fallocate instead of
I haven't done a full review, but I can answer one of your questions:
On 03/27/2015 07:13 AM, Mark Wielaard wrote:
>> +cu_iterator
>> +operator++ ()
>> +{
>> + move ();
>> + return *this;
>> +}
>> +
>> +cu_iterator
>> +operator++ (int)
>> +{
>> + cu_itera
On 02/12/2015 03:32 AM, Mark Wielaard wrote:
> On Thu, 2015-02-12 at 00:22 +0100, Petr Machata wrote:
>> Josh Stone writes:
>>
>>> With CFLAGS='-Og -g', F21 gcc hits -Werror=maybe-uninitialized in
>>> read_encoded_value at "*result += value".
atch initializes jmp anyway to convince gcc it's ok.
Signed-off-by: Josh Stone
---
tests/ChangeLog | 4
tests/backtrace.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/ChangeLog b/tests/ChangeLog
index 97c7ab88c1d3..3db06b4b5c7d 100644
--- a/tests/Chan
re for
error cases, which will then return immediately. This patch just sets
value = 0 to begin with, so gcc is always convinced it's fine.
Signed-off-by: Josh Stone
---
libdw/ChangeLog | 4
libdw/encoded-value.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git
On 01/25/2015 11:39 AM, Hanno Böck wrote:
> Hi,
>
> Please see attached file, which is a malformed (fuzzed) elf file that
> causes elfutil's readelf -e to hang, testet with the latest version
> 0.161.
>
> This was found with zzuf.
You should be fuzzing with git master, as Mark is still making a
On 01/25/2015 11:42 AM, Hanno Böck wrote:
> Hi,
>
> When compiling elfutils with undefined behaviour sanitizer
> (-fsanitize=undefined) a warning will be shown indicating an invalid
> shiftleft operation on the attached elf file:
>
> readelf.c:1133:28: runtime error: left shift of 1 by 31 places
On 01/16/2015 08:02 AM, Mark Wielaard wrote:
> On Fri, 2015-01-16 at 06:12 -0800, Anatol Pomozov wrote:
>> On Thu, Jan 15, 2015 at 3:06 AM, Mark Wielaard wrote:
>>> Awesome! BTW. Which architecture and what are the two SKIPPED tests?
>>>
>> I have x86_64 and the skipped tests are
>>
>> SKIP: run-b
On 01/12/2015 01:25 PM, Mark Wielaard wrote:
> On Sat, 2014-12-27 at 16:49 +0100, Mark Wielaard wrote:
>> I think you are right and those tests, addrscopes and funcscopes, are
>> wrong. They use dwfl_module_getsrc to find the line associated with start
>> and end of the scope. But for the end they
On 01/14/2015 08:47 AM, Mark Wielaard wrote:
> On Wed, 2015-01-14 at 09:26 -0500, Jason P. Leasure wrote:
>> The type_offset of a type unit header is relative to the beginning
>> of the type unit header.
>>
>> Signed-off-by: Jason P. Leasure
>> ---
>> libdw/dwarf_formref_die.c | 2 +-
>> 1 file c
On 12/24/2014 05:27 AM, Mark Wielaard wrote:
> In commit 7d9b5a dwfl_module_getsrc was changed so that it returns the last
> line record <= addr, rather than returning immediately on a match. This
> changes dwarf_getsrc_die to do the same. And it adds a new test that checks
> this by comparing agai
On 12/16/2014 02:10 AM, Mark Wielaard wrote:
>> I think src/elfcmp.c compare_Elf32_Word() is also wrong, as big u32
>> values could wrap int subtraction. I didn't find any others.
>
> Ah, missed that Elf32_Word is unsigned. There is an assert that makes
> sure it is at least as wide as an int, bu
On 12/13/2014 03:18 PM, Mark Wielaard wrote:
> On Thu, Dec 11, 2014 at 05:34:06PM -0800, Josh Stone wrote:
>> BTW, I want to point out this change in compare_lines:
>>
>>> - return (*p1)->addr - (*p2)->addr;
>> [...]
>>> + if (line1->addr != l
On 12/15/2014 01:11 PM, Mark Wielaard wrote:
> On Mon, 2014-12-15 at 11:05 -0800, Josh Stone wrote:
>> +2014-12-15 Josh Stone
>> +
>> +* .gitignore: Add config/compile as installed by automake 1.14.
>
> Yes, please.
Pushed.
Signed-off-by: Josh Stone
---
On Fedora 21, this appears to be slightly faster, although pretty close
to noise levels. Mark, can you see if this helps the performance slip
on your el7 system?
---
libdw/ChangeLog | 6 ++
libdw/memory-access.h | 17 +++--
2 files changed
On 12/14/2014 02:18 PM, Mark Wielaard wrote:
> This finally adds bounds checking to get_[us]leb128 (with two exceptions,
> see below). The performance results are a little puzzling, so I hope
> Josh can take a look how things are for him.
>
> On one system, with 3.10.0-123.13.1.el7.x86_64, varlocs
Signed-off-by: Josh Stone
---
.gitignore | 1 +
ChangeLog | 4
2 files changed, 5 insertions(+)
diff --git a/.gitignore b/.gitignore
index 1eda00b80774..8e33bb9b5114 100644
--- a/.gitignore
+++ b/.gitignore
@@ -26,6 +26,7 @@ config.h.in
config.log
config.status
config/ar-lib
+config
On 12/12/2014 07:54 AM, Mark Wielaard wrote:
> @@ -513,6 +515,7 @@ __libdw_form_val_len (Dwarf *dbg, struct Dwarf_CU *cu,
>uint8_t len = form_lengths[form];
>if (len != 0)
> {
> + const const unsigned char *endp = cu->endp;
> len &= 0x7f; /* Mask to allow 0x80 ->
On 12/11/2014 05:23 PM, Josh Stone wrote:
> This set changes dwarf_getsrclines into a stable sort, adjusts the binary
> search in dwfl_module_getsrc to pick the last match, and finally adds a test
> for earlier addr2line fixes.
>
> ---
> libdw/ChangeLog |
On 12/13/2014 11:42 AM, Mark Wielaard wrote:
> On Thu, Dec 11, 2014 at 05:23:36PM -0800, Josh Stone wrote:
>> Now that libdw's srclines use a stable sort, we can reliably choose the
>> *last* matching line record for a given address, which should be the
>> innermost w
BTW, I want to point out this change in compare_lines:
> - return (*p1)->addr - (*p2)->addr;
[...]
> + if (line1->addr != line2->addr)
> +return (line1->addr < line2->addr) ? -1 : 1;
Since addr is 64-bit unsigned, and comparison functions return int, it
is possible for the difference to be
This set changes dwarf_getsrclines into a stable sort, adjusts the binary
search in dwfl_module_getsrc to pick the last match, and finally adds a test
for earlier addr2line fixes.
---
libdw/ChangeLog | 7
libdw/dwarf_getsrclines.c | 52 +--
This test is for the fix in commit aecdf2670c02, but it was hampered by
unlucky sorting of line records. With the new stable sort, the test now
gets the desired line numbers.
Signed-off-by: Josh Stone
---
tests/ChangeLog | 8 +
tests/Makefile.am | 4
This adds a sequence number to the linked-list entries, so the original
order can break ties in sorting, making this a stable sort.
Signed-off-by: Josh Stone
---
libdw/ChangeLog | 7 +++
libdw/dwarf_getsrclines.c | 52 ---
2 files
Now that libdw's srclines use a stable sort, we can reliably choose the
*last* matching line record for a given address, which should be the
innermost where inlines are concerned.
Signed-off-by: Josh Stone
---
libdwfl/ChangeLog| 5 +
libdwfl/dwfl_module_getsrc.c
9 @@
> +2014-12-11 Mark Wielaard
> +
> + * dwarf_child.c (__libdw_find_attr): Call __libdw_form_val_len with
> + die->cu->endp, not the abbrev endp.
> + * dwarf_getattrs.c (dwarf_getattrs): Likewise.
> +
> 2014-12-10 Josh Stone
>
> * libdwP.h (Dwarf_CU)
On 12/10/2014 11:41 AM, Josh Stone wrote:
> As previously discussed, these patches fix the function names for addr2line.
> For addr2line -i, it now walks as many scopes as necessary to find the
> containing function, instead of assuming it's the next scope. Also, addr2line
On 12/10/2014 06:48 PM, Josh Stone wrote:
> While looking at performance for Mark's form-len patch, I found a few areas
> that I felt could be cleaned up a bit.
>
> 1. die->abbrev initialization was duplicated in a few places.
> 2. dwarf_hasattr needn't look at the
Rather than looking up section data every time, we can simply save the
range of each CU as pointers in Dwarf_CU.
Signed-off-by: Josh Stone
---
libdw/ChangeLog | 8
libdw/dwarf_child.c | 3 +--
libdw/dwarf_cuoffset.c | 4 ++--
libdw/dwarf_dieoffset.c | 4 ++--
libdw
Add a new internal function, __libdw_dieabbrev, which deals with checking
a die for an abbrev, and setting it as needed.
Signed-off-by: Josh Stone
---
libdw/ChangeLog | 8
libdw/dwarf_child.c | 44 +---
libdw/dwarf_getattrs.c
To just check the presence of an attribute, we only need to look at the
abbreviation data. This optimization avoids reading over die data at all,
except possibly just to get the abbrev code.
Signed-off-by: Josh Stone
---
libdw/ChangeLog | 3 +++
libdw/dwarf_hasattr.c | 42
While looking at performance for Mark's form-len patch, I found a few areas
that I felt could be cleaned up a bit.
1. die->abbrev initialization was duplicated in a few places.
2. dwarf_hasattr needn't look at the die at all, just abbrev.
3. CU start/end boundaries don't need to be computed from s
Signed-off-by: Josh Stone
---
src/ChangeLog | 6 +-
src/addr2line.c | 40
tests/ChangeLog | 5 +
tests/run-addr2line-i-test.sh | 4 +++-
4 files changed, 33 insertions(+), 22 deletions(-)
diff --git
The function which contains an inline might not be the immediate next
die scope. For instance, there may be a lexical scope in between.
Instead, iterate the remaining scopes until an appropriate tag is found.
Signed-off-by: Josh Stone
---
src/ChangeLog | 4
src/addr2line.c | 17
As previously discussed, these patches fix the function names for addr2line.
For addr2line -i, it now walks as many scopes as necessary to find the
containing function, instead of assuming it's the next scope. Also, addr2line
now prefers linkage_name over the plain die name in all cases.
I haven'
On 12/07/2014 05:23 PM, Petr Machata wrote:
> Josh Stone 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
On 12/04/2014 01:00 PM, Mark Wielaard wrote:
> This solves a couple of crashers reported by Alexander.
>
> This will probably have some performance impact, but I haven't measured
> it yet. It would be good to have some performance tests. We also need
> some overflow check for leb128 reading.
>
>
On 11/21/2014 07:52 AM, Mark Wielaard wrote:
> On Tue, 2014-11-18 at 18:04 -0800, Josh Stone wrote:
>> I have a simple patch attached to improve the output addr2line -fi. The
>> problem I had is it failed to identify the parent function name if there
>> was any lexic
Hi,
I have a simple patch attached to improve the output addr2line -fi. The
problem I had is it failed to identify the parent function name if there
was any lexical_block in the scope hierarchy. For example, try the
following, compiled as the attached testfile-lex-inlines.bz2:
1 // g++ x.cpp
On 10/31/2014 11:26 AM, Petr Machata wrote:
> Mark Wielaard 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 w
On 10/10/2014 11:42 AM, Roland McGrath wrote:
> The description in your prologue and the libdw.h comment do not match what
> the code actually does. You describe it as going until it hits one of the
> known categories of actual type. But what it actually does is go only as
> long as it is seeing
On 10/01/2014 11:34 AM, Conrad Rad wrote:
> What was the issue with MIPS pointers, by the way?
https://sourceware.org/ml/systemtap/2014-q3/msg00071.html
(this was on elfutils-devel too, but that archive breaks this thread
across July/August)
So 64-bit MIPS may have some CU address_size == 4. I w
On 10/01/2014 10:15 AM, Conrad Rad wrote:
> Hi all,
>
> First, I'm not super familiar with DWARF, and perhaps this is a bug in
> the DWARF information emitted by Clang (3.4). It's definitely a
> difference between GCC and Clang DWARF output.
>
> I've been fiddling with a pahole-alike tool[0] that
FYI, I just pushed commit f1ec744b5747 to shield a sed expression from
autoconf's replacement. That was causing every instance of "ar" in
make-debug-archive to be replaced with a full path.
This phenomenon was reported by SamB on IRC.
---
This is free softw/usr/local/bin/are
There is NO w/usr/lo
On 06/18/2014 11:38 AM, Mark Wielaard wrote:
> And a future version of DWARF might
> use the number for a completely different purpose.
The issue you linked says this:
Remove DW_TAG_mutable_type from Appendix A (Figure 17)
(Make sure not to reassign the number 0x3e to another tag.
Perha
On 06/18/2014 02:48 AM, Mark Wielaard wrote:
> The DW_TAG_mutable_type was only mentioned in an early draft of DWARFv3.
> But was removed because there are no C++ mutable qualified types. It was
> replaced by a new attribute DW_AT_mutable on DW_TAG_member DIEs. The new
> attribute is available in d
On 04/23/2014 11:51 AM, Richard Henderson wrote:
> On 04/23/2014 11:32 AM, Petr Machata wrote:
>> Richard Henderson writes:
>>
>>> On 04/23/2014 03:17 AM, Petr Machata wrote:
Wouldn't something like this get us off the hook as well?
- (var) |= (typeof (var)) __s.i << ((nth) * 7);
On 04/22/2014 08:01 AM, Richard Henderson wrote:
> On 04/22/2014 07:55 AM, Mark Wielaard wrote:
>> On Thu, 2013-12-12 at 11:06 -0800, Josh Stone wrote:
>>> On 12/12/2013 04:13 AM, Petr Machata wrote:
>>>> Josh Stone writes:
>>>>
On 04/07/2014 08:55 AM, Florian Weimer wrote:
> Thanks for the explanation. I find it kind of surprising that libdw
> goes behind my back and opens random files based on paths extracted from
> the data I supply. I would have expected that from libdwfl, not libdw.
Yes, in fact this was in Mark'
ned-off-by: Josh Stone
---
tests/ChangeLog | 7 +
tests/Makefile.am| 2 +-
tests/run-dwflsyms.sh| 48 +
tests/run-readelf-s.sh | 77 +++
tests/testfilebaxmin.bz2 | Bin 0 -> 2987 bytes
5 files
On 03/10/2014 02:23 PM, Mark Wielaard wrote:
> On Fri, 2014-03-07 at 17:39 -0800, Josh Stone wrote:
>> The gist is that I have an ET_EXEC binary, /usr/bin/ls. When I call
>> dwfl_module_getsymtab -> find_symtab -> find_aux_sym -> open_elf, the
>> following heurist
Please see: https://sourceware.org/bugzilla/show_bug.cgi?id=16676#c2
I'm using elfutils-0.158-1.fc20.x86_64, but I don't think git libdwfl
has changed in any relevant way since then.
The gist is that I have an ET_EXEC binary, /usr/bin/ls. When I call
dwfl_module_getsymtab -> find_symtab -> find_
On 02/25/2014 01:43 AM, Florian Weimer wrote:
> On 02/24/2014 05:54 PM, Mark Wielaard wrote:
>
>>> Is there a reliable way to recognize separate debugging information?
>>> Then I could avoid extracting data from phdrs.
>>
>> I looked a bit into this and I don't see any way to detect that the
>> ph
On 02/05/2014 09:36 AM, Josh Stone wrote:
> On 02/05/2014 03:44 AM, Mark Wielaard wrote:
>> On Tue, 2014-02-04 at 18:24 -0800, Josh Stone wrote:
>>> So now I'm not sure anything needs to change. At least dwarf_formsdata
>>> should stay as-is for gcc.
>>
On 02/05/2014 11:58 AM, Josh Stone wrote:
> Also, an assertion on the range of line/column is now a handled error,
> setting DWARF_E_INVALID_DWARF for values greater than INT_MAX.
Note, this is not so much INVALID as UNSUPPORTED, really, as the current
API can only deal with int values. I
rror,
setting DWARF_E_INVALID_DWARF for values greater than INT_MAX.
Signed-off-by: Josh Stone
---
libdw/ChangeLog | 6 ++
libdw/dwarf_decl_file.c | 4 ++--
libdw/dwarf_decl_line.c | 13 +
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/libdw/ChangeLog b/l
On 02/05/2014 03:44 AM, Mark Wielaard wrote:
> On Tue, 2014-02-04 at 18:24 -0800, Josh Stone wrote:
>> On 02/04/2014 03:12 PM, Josh Stone wrote:
>>> There are only a few internal dwarf_formsdata calls: for the decls as I
>>> mentioned, and in array_size() for DW_AT_low
On 02/04/2014 03:12 PM, Josh Stone wrote:
> There are only a few internal dwarf_formsdata calls: for the decls as I
> mentioned, and in array_size() for DW_AT_lower/upper_bound. AFAICS the
> spec doesn't explicitly call bounds signed or unsigned, but only
> unsigned makes sens
s I
mentioned, and in array_size() for DW_AT_lower/upper_bound. AFAICS the
spec doesn't explicitly call bounds signed or unsigned, but only
unsigned makes sense to me, so these also ought to use dwarf_formudata.
I don't know what to say about external callers... :/
On 02/04/2014 0
Hi,
I was just investigating some signed-value inconsistencies I found
between libdwarf and libdw, while working on a little experiment[1]. I
think elfutils is actually handling dwarf_formsdata incorrectly.
Libdwarf doesn't have dwarf_decl_line et al., so I was coding that bit
manually, but I go
On 12/17/2013 01:59 AM, Mark Wielaard wrote:
> On Mon, 2013-12-16 at 11:16 -0800, Josh Stone wrote:
>> On 12/16/2013 06:17 AM, Mark Wielaard wrote:
>>> On Sat, 2013-12-14 at 13:51 -0800, Josh Stone wrote:
>>>> In Fedora, these paths are relative to the debug file i
On 12/16/2013 03:29 PM, Roland McGrath wrote:
>> In Fedora, these paths are relative to the debug file itself, so that's
>> a better thing to try first. We don't actually have the debug path in
>> libdw, but we can usually find it from elf->fildes and /proc/self/fd/.
>
> That's even more barfalic
debug file itself, so that's
a better thing to try first. We don't actually have the debug path in
libdw, but we can usually find it from elf->fildes and /proc/self/fd/.
Signed-off-by: Josh Stone
---
PS - Mark tipped me to use git-merge-changelog, but that doesn't seem to
worry
On 12/16/2013 02:18 PM, Roland McGrath wrote:
>> + /* Note that form_lengths[flag_present] is 0, like every other absent
>> index.
>> + * But since flag_present's length truly is 0, check for it explicitly.
>> */
>
> Extra * is bad comment formatting.
Right, Petr caught that on v2. These a
On 12/16/2013 06:17 AM, Mark Wielaard wrote:
> On Sat, 2013-12-14 at 13:51 -0800, Josh Stone wrote:
>> The existing code was first trying .gnu_debugaltlink paths directly, so
>> relative paths would start from the current program's working directory.
>> That's u
debug file itself, so that's
a better thing to try first. We don't actually have the debug path in
libdw, but we can usually find it from elf->fildes and /proc/self/fd/.
Signed-off-by: Josh Stone
---
libdw/ChangeLog| 5 +
libdw/dw
With fixed comment formatting, these patches are now pushed.
Thanks!
Josh
This removes the IS_LIBDW distinction so LEB128 operations are now
always inlined, and the implementations are simplified, more direct.
Signed-off-by: Josh Stone
---
libdw/ChangeLog | 15 +++
libdw/Makefile.am | 3 +-
libdw/dwarf_getlocation.c | 3 +-
libdw/memory
x27;s conceivable that a smart compiler could make a similar
lookup transformation from the large switch itself, but GCC doesn't.)
Signed-off-by: Josh Stone
---
libdw/ChangeLog| 6 ++
libdw/libdwP.h | 36 +---
libdw/libdw_f
s are frequently created anew, and need to find abbrev each
time, so even that one division becomes a noticeable hotspot. This
patch adds a branch to avoid it, which is very predictable for the CPU.
Signed-off-by: Josh Stone
---
lib/ChangeLog | 4
lib/dynamicsizehash.c | 5 +++--
2
Thanks to Petr for the reviews - I made these changes:
Patch 1: Use 0x80 to represent flag_present's 0 in the table.
Patch 2: Added a comment for the manually unrolled step 0 of uleb128,
and made both get_?leb128 macros into simple expressions. Fixed the
one caller who was getting a set-but-unu
On 12/12/2013 11:16 AM, Josh Stone wrote:
> On 12/12/2013 09:07 AM, Petr Machata wrote:
>> Josh Stone writes:
>>
>>> struct Dwarf_CU
>>> {
>>> @@ -283,7 +285,9 @@ struct Dwarf_CU
>>>size_t type_offset;
>>>uint64_t
On 12/12/2013 09:07 AM, Petr Machata wrote:
> Josh Stone writes:
>
>> struct Dwarf_CU
>> {
>> @@ -283,7 +285,9 @@ struct Dwarf_CU
>>size_t type_offset;
>>uint64_t type_sig8;
>>
>> - /* Hash table for the abbreviations. */
>> +
On 12/12/2013 04:13 AM, Petr Machata wrote:
> Josh Stone writes:
>> +static inline uint64_t
>> +__libdw_get_uleb128 (const unsigned char **addrp)
>> +{
>> + uint64_t acc = 0;
>> + get_uleb128_step (acc, *addrp, 0);
>> + for (unsig
1 - 100 of 147 matches
Mail list logo
