profile
viewpoint

m4b/goblin 538

An impish, cross-platform binary parsing crate, written in Rust

gimli-rs/gimli 396

A blazing fast library for consuming the DWARF debugging format

m4b/faerie 175

Magical ELF and Mach-o object file writer backend

gimli-rs/ddbug 35

Display debugging information

gimli-rs/leb128 9

Read and write DWARF's "Little Endian Base 128" variable length integer encoding

philipc/findpanics 8

Find calls to panic functions in rust executables

pull request commentrust-lang/backtrace-rs

Support Mach-O backtraces without dsymutil

Oh not much probably! If you'd prefer to land it ungated I don't mind reviewing accordingly. I think though it's nothing really out of the ordinary, just a thorough review, tests, CI, etc.

I think that should be doable, but hold off until I get CI passing (this needs a least new object release). I assume the existing tests with RUSTFLAGS="-Z run-dsymutil=no" will be enough?

Would it be possible to have some sort of indexed-by-address map of some sort? I'm not really sure how this debuginfo stuff works, but can we always say that everything within a range of addresses will lie in the same object file? Ideally we could have a Vec of objects which is sorted by the addresses they show up at, and then we can just lookup an address in this list first to find the dwarf info for a symbol. Failing that we could try the main file or loading the object lazily.

I don't think there is any guarantee that each object will be a contiguous address range, so we can't exactly do that. The next best thing is a Vec of symbols sorted by addresses, and we already have that in object::ObjectMap. So we do a binary search for the address which gives us an object index, then use the object index to directly get the dwarf info for that object, then look up the address in the dwarf info.

Another reason we need it to be a Vec of symbols is that the addresses in the dwarf haven't been relocated, so object::ObjectMap also contains the symbol names, which lets us look up the original symbol in the object file to "unrelocate" the address (currently this is a linear scan, but could be changed to a binary search or a hash map).

philipc

comment created time in 4 hours

pull request commentgimli-rs/object

Add `ObjectMap`

@mstange You've previously expressed an interest in this functionality; do you think this meets your needs?

philipc

comment created time in a day

pull request commentrust-lang/backtrace-rs

Support Mach-O backtraces without dsymutil

I think that this looks great and would be happy to land it feature gated.

What do you think it would take to not need to be gated?

For caching, I wonder if we could perhaps just have an infinitely-sized "cache" inside of each object? That way the LRU can take care of top-level things, but each top-level thing is allowed to be arbitrarily big (which sorta makes sense to me). Basically each Object in backtrace would have a Vec of loaded member objects, populated lazily of course.

Yeah, that's the kind of thing I was expecting. By "infinitely-sized", were you expecting that we'd do a linear scan for the object file name? Instead, since we can already identify each object file by an index, I've used that to index into a presized Vec. It doesn't try to share mmaps for archives though. I was actually wondering if the OS would be smart enough to make that cheap.

philipc

comment created time in a day

PR opened gimli-rs/object

Add `ObjectMap`

Maps from addresses to symbol names and object file names using Mach-O STAB entries.

+237 -13

0 comment

8 changed files

pr created time in a day

push eventphilipc/backtrace-rs

Philip Craig

commit sha 7d5078df7bd60755712a8c161ff0942c8673b940

Support Mach-O backtraces without dsymutil

view details

push time in a day

push eventphilipc/backtrace-rs

Philip Craig

commit sha fd5451e74ee0f48d98c73c6dc2b48a5fb8b79feb

Support Mach-O backtraces without dsymutil

view details

push time in a day

push eventphilipc/object

Philip Craig

commit sha 794b615cdf45cf656387710e51117a7624a2477c

Add `ObjectMap` Maps from addresses to symbol names and object file names using Mach-O STAB entries.

view details

push time in a day

push eventphilipc/object

Philip Craig

commit sha 6213eaf869bddfbd59684d2ad8827254a9b3abf6

Add `ObjectMap` Maps from addresses to symbol names and object file names using Mach-O STAB entries.

view details

push time in a day

push eventphilipc/backtrace-rs

Philip Craig

commit sha 890f092ca223ec45ba12a7b6b0909aa823bd58ab

Support Mach-O backtraces without dsymutil

view details

push time in a day

create barnchphilipc/backtrace-rs

branch : macho-split-2

created branch time in a day

push eventphilipc/object

Philip Craig

commit sha ff7547be595076ed66672c58aabcd32f3d63f3a4

read: add archive support

view details

Philip Craig

commit sha 28d1cef44e5e503cb1645d269f239b0073a45b37

Merge pull request #252 from philipc/archive read: add archive support

view details

Philip Craig

commit sha f28b7f6518fa727c800c4853d8d1864cd13614ff

Add `ObjectMap` Maps from addresses to symbol names and object file names using Mach-O STAB entries.

view details

push time in a day

issue commentgimli-rs/object

Implement relocations for dynamic symbols in elf

@matprec Do you think you'll be able to publish your current work somehow? It doesn't need to be finished or rebased.

matprec

comment created time in 2 days

delete branch philipc/object

delete branch : archive

delete time in 2 days

push eventgimli-rs/object

Philip Craig

commit sha ff7547be595076ed66672c58aabcd32f3d63f3a4

read: add archive support

view details

Philip Craig

commit sha 28d1cef44e5e503cb1645d269f239b0073a45b37

Merge pull request #252 from philipc/archive read: add archive support

view details

push time in 2 days

PR merged gimli-rs/object

read: add archive support

Doesn't support reading the symbol table yet.

+504 -1

2 comments

6 changed files

philipc

pr closed time in 2 days

push eventphilipc/object

Philip Craig

commit sha ff7547be595076ed66672c58aabcd32f3d63f3a4

read: add archive support

view details

push time in 2 days

PR opened rust-lang/backtrace-rs

Support Mach-O backtraces without dsymutil

This is currently all horrible code, and it doesn't cache anything, but it passes the tests. It depends on some unmerged changes in object, so I'll get them cleaned up and merged first.

+68 -3

0 comment

3 changed files

pr created time in 3 days

create barnchphilipc/backtrace-rs

branch : macho-split

created branch time in 3 days

push eventphilipc/object

Philip Craig

commit sha 02157994b4b36a00a84aede534aa499150edb48d

read: add archive support

view details

Philip Craig

commit sha ab61e1940bb7433d079e1514c6694e5302877efd

Add `ObjectMap` Maps from addresses to symbol names and object file names.

view details

Philip Craig

commit sha 01cc354e5f0cb598a12239967a36283ec196ab96

read/macho: add Nlist::is_undefined() back in

view details

push time in 3 days

push eventphilipc/addr2line

Philip Craig

commit sha 65f215492371a153b211e59959239061bdfbd376

WIP

view details

push time in 3 days

pull request commentgimli-rs/object

read: add archive support

Have you seen the ar crate?

Yes I have: https://github.com/rust-lang/backtrace-rs/issues/287#issuecomment-706064938

Also I think you are not handling archive members with an odd size. Those get an extra padding byte.

I think this is handled correctly already, but I'll test properly later.

philipc

comment created time in 9 days

PR opened gimli-rs/object

read: add archive support

Doesn't support reading the symbol table yet.

+379 -1

0 comment

6 changed files

pr created time in 9 days

create barnchphilipc/object

branch : archive

created branch time in 9 days

issue commentm4b/goblin

Elf: NoteIterator has an infinite loop

By the way, that file_core_arm_pi.zip has a lot of stuff wrong with it (e.g. try running readelf on it). So while goblin should do better, you are trying to run it on something that is corrupted or invalid.

m4b

comment created time in 9 days

issue commentm4b/goblin

Elf: NoteIterator has an infinite loop

The hang is actually on notes_iter.count(). So yes it's the same problem as described in this issue: currently you must not continue iterating after an error occurs or you'll get an infinite loop (and count will always continue iterating).

m4b

comment created time in 9 days

issue commentm4b/goblin

feature request, remove the dependes on log or make it optional.

Those look like you're using this in rustc, not c runtime?

If you're using this in rustc, then use the object crate instead, since it already has support for this and is used by backtrace-rs already. The object crate doesn't support as much as goblin, but additions are welcome.

lygstate

comment created time in 10 days

issue commentrust-lang/backtrace-rs

Support for split debuginfo

Is there already a crate that handles parsing stabs debug info?

They coexist with other symbols, so existing Mach-O parsers can read them, and it's simple enough to get the information we need without a full stabs debug info parser.

It is probably worthwhile to at least ensure that whatever you design here won't need major changes to work with DWARF split debuginfo, since that would be a valuable addition.

My feeling is that there will be little in common beyond the DWARF parsing itself, which is already done. We currently only support native backtraces, and the parsing of each file format is already separated, so I don't expect much need or possibility for sharing.

Thanks for that list. The ELF/Mach-O cases cover everything I know about. I don't know much about PDB.

philipc

comment created time in 12 days

issue commentrust-lang/backtrace-rs

Support for split debuginfo

What we have is a list of symbols for each object that was linked in the executable/library. The object is specified by an N_OSO symbol that is either an object file name (/path/to/object.o), or an object within an archive (/path/to/archive.a(object.o)), and is followed by N_FUN etc symbols for each symbol from that object which was linked in. The symbolication logic needs to be something like:

  • determine which executable/library contains the address
  • lookup the symbol for that address (and this lookup can find the object/archive path too)
  • load the object (this is the step I was talking about above)
  • lookup the symbol in that object so that the address can be translated
  • parse the DWARF in that object and lookup the translated address
philipc

comment created time in 15 days

push eventgimli-rs/leb128

Lua MacDougall

commit sha 6e335192580c3379ee62a4d414d37e4a91cd3023

Overflow no longer leaves LEB128 values half-read Originally, if an overflow condition was triggered while decoding a LEB128-encoded value in an io::Read, an Error::Overflow would be immidiately returned. This immidiate return could possibly leave some of the LEB128-encoded value left in the io::Read, making later decoding operations return incorrect results and making graceful error recovery impossible.

view details

Lua MacDougall

commit sha 8c7e194cdb4812bec197bed0c8d46a43a6284e7e

Added test case test_read_multiple_with_overflow with example from issue I've added a test case called test_read_multiple_with_overflow that verifies that the bug described in this issue no longer occurs: https://github.com/gimli-rs/leb128/issues/14#issue-716117130

view details

Philip Craig

commit sha 1b17164b655aaf654dc86e51eabd0fe2d9f65de7

Merge pull request #15 from luawtf/codespace-1 Overflow no longer leaves LEB128 values half-read

view details

push time in 16 days

PR merged gimli-rs/leb128

Overflow no longer leaves LEB128 values half-read

Fixes #14

+29 -0

0 comment

1 changed file

luawtf

pr closed time in 16 days

issue closedgimli-rs/leb128

Overflowing while reading can create "phantom numbers" which can possibly cause corrupt/incorrect output

I'm currently using leb128 to read LEB128-encoded numbers from a stream of data (TcpStream) and I encountered a serious bug that caused my application to generate corrupt/incorrect output and could possibly allow for a DoS attack (in my case).

To describe this bug, assume that cursor is my TcpStream and that I am attempting to read TWO (2) LEB128-encoded numbers from it.

Without an overflow, this library works fine:

let mut cursor = std::io::Cursor::new(vec![
  0b1000_0011, 0b0010_1110,              // 5891
  0b1110_0100, 0b1110_0000, 0b0000_0010, // 45156
]);

for call in 1..4 {
  println!("Call #{}: {:?}", call, leb128::read::unsigned(&mut cursor));
}
// Call #1: Ok(5891)  // Number one
// Call #2: Ok(45156) // Number two
// Call #3: Err(IoError(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" }))

However, when an overflow occurs while reading a very long LEB128 value, a phantom 3rd number appears!

let mut cursor = io::Cursor::new(vec![
  0b1111_1111, 0b1111_1111, 0b1111_1111, 0b1111_1111,
  0b1111_1111, 0b1111_1111, 0b1111_1111, 0b1111_1111,
  0b1111_1111, 0b1111_1111, 0b0111_1111, // Overflow!
  0b1110_0100, 0b1110_0000, 0b0000_0010, // 45156
]);

for call in 1..5 {
  println!("Call #{}: {:?}", call, leb128::read::unsigned(&mut cursor));
}

// Call #1: Err(Overflow) // Number one
// Call #2: Ok(127)       // Where did you come from??
// Call #3: Ok(45156)     // Number two
// Call #4: Err(IoError(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" }))

This happens because both leb128::read::signed and leb128::read::unsigned exit early if an overflow occurs:

pub fn unsigned<R>(r: &mut R) -> Result<u64, Error>
where
    R: io::Read,
{
    let mut result = 0;
    let mut shift = 0;

    loop {
        let mut buf = [0];
        r.read_exact(&mut buf)?;

        if shift == 63 && buf[0] != 0x00 && buf[0] != 0x01 { // <<<<<<<<<<<<<<<<
            return Err(Error::Overflow);                     // <<<<<<<<<<<<<<<<
        }                                                    // <<<<<<<<<<<<<<<<

        let low_bits = low_bits_of_byte(buf[0]) as u64;
        result |= low_bits << shift;

        if buf[0] & CONTINUATION_BIT == 0 {
            return Ok(result);
        }

        shift += 7;
    }
}

The condition that causes return Err(Error::Overflow); to execute can evaluate to true before the entire LEB128 value has been read, leaving behind extra bytes that can cause serious issues.

closed time in 16 days

luawtf
PullRequestReviewEvent

issue commentrust-lang/backtrace-rs

Support for split debuginfo

I've started looking at the macOS support for this again, and have a rough proof of concept for the addr2line crate, which should port to this crate fairly simply.

One thing it requires (and which I haven't attempted yet) is the ability to read objects in archives. I'm not sure what sort of efficiency/complexity trade-offs we should be making for this. Here's some possible strategies:

  • mmap the archive once for each object, even if this means an archive is mapped multiple times. These would be stored alongside the existing mmap for the executable or shared library, and freed when its LRU cache entry is removed.
  • Create a hashmap of archive mmaps that can be reused, and use reference counting to determine when they can be freed.
  • Read each object into a Vec.

For reading archives there is the ar crate, but it seems to only provide a streaming interface, so that would work better with reading into a Vec. This would be another dependency though. I think archive support is simple enough that it could be added to the object crate instead of adding another dependency.

philipc

comment created time in 16 days

push eventphilipc/addr2line

Philip Craig

commit sha d07e9b1df3de352432b06cdada47dd59fc576db9

WIP

view details

push time in 16 days

pull request commentrust-lang/backtrace-rs

use NativeEndian in symbolize::gimli::Context

Hmm, then should we make this import part of the platform-specific cfg_if?

This import seems to only be used for the DWARF, and I don't know what endianness DWARF in PE uses. My intuition is that NativeEndian would be correct for it too.

cuviper

comment created time in 16 days

pull request commentrust-lang/backtrace-rs

use NativeEndian in symbolize::gimli::Context

I actually thought that ELF was always little-endian for common platforms, regardless of the endianness of the platform itself

I think that's true for PE but not for ELF.

cuviper

comment created time in 16 days

push eventphilipc/object

Philip Craig

commit sha c89734395d91384dad8a93d8f57bac5da4e3d28f

Add `ObjectMap` Maps from addresses to symbol names and object file names.

view details

push time in 17 days

create barnchphilipc/addr2line

branch : oso

created branch time in 17 days

create barnchphilipc/object

branch : object-map

created branch time in 18 days

issue commentgimli-rs/leb128

Overflowing while reading can create "phantom numbers" which can possibly cause corrupt/incorrect output

For most uses, it is expected that overflows are abnormal and if they occur then that is an indication that the input data is corrupted and cannot be reliably read anyway. That is, if the corruption caused an overflow, how can you be sure where the LEB128 value really ends? If your TCP sender is deliberately producing values that overflow, then it might be better to change that behaviour instead.

I don't think your DoS concern is a valid reason to change this. If an attacker can cause this situation to occur, then they could just as easily cause a situation where there are more numbers than you expect. You should be designing your application to handle this anyway.

The error handling could be changed to keep reading bytes until the continuation bit is clear, but I'm unsure what the behaviour should be if a read error then occurs while doing that.

luawtf

comment created time in 18 days

push eventphilipc/object

Philip Craig

commit sha fe7ee4ea0f202aa3639a2fc2b60bbf49996711bf

Add `SourceMap` Maps from addresses to symbol/file/object.

view details

push time in 20 days

push eventphilipc/object

Philip Craig

commit sha 0367bdae59d6fcb0e3619443f3ea921769103cd4

Add `SourceMap` Maps from addresses to symbol/file/object.

view details

push time in 21 days

push eventphilipc/object

Philip Craig

commit sha d866da4c25ce2d0cc726104b22f76fa17ad4e6c9

Add `SourceMap` Maps from addresses to symbol/file/object.

view details

push time in 23 days

create barnchphilipc/object

branch : source-map

created branch time in 23 days

pull request commentgimli-rs/unwind-rs

Rename README to README.md

@RushiVachhani It's unclear what you are referring to, since there was nothing this PR needed besides merging. Perhaps create a new issue if needed.

mominul

comment created time in a month

push eventgimli-rs/unwind-rs

Muhammad Mominul Huque

commit sha 58911543aaebfb476bc096d8148b8d24df3be71f

Rename README to README.md Absence of `md` extension causing GitHub to not render the `README` file.

view details

Philip Craig

commit sha d7e9b02c9b59886843ebd7ee850dc219a18df44e

Merge pull request #40 from mominul/patch-1 Rename README to README.md

view details

push time in a month

PR merged gimli-rs/unwind-rs

Rename README to README.md

The absence of md extension was causing GitHub to not render the README file.

+0 -0

1 comment

1 changed file

mominul

pr closed time in a month

delete branch philipc/object

delete branch : symbol-map

delete time in a month

push eventgimli-rs/object

Philip Craig

commit sha 626b520b63613bf0a69e74d04ec90db01430ae61

Replace `Symbol` with a trait This allows users to only store the parts of the symbol that they are interested in. For example, the user may want to only store the symbol index and retrieve specific details from the symbol table only as needed. `Object::symbol_map` now returns a map containing only symbol names and addresses, which is the most common use case. `SymbolMap` can be constructed with custom symbol entries if other information is required. This method also uses the dynamic symbol table if there are no debugging symbols. Also fixes COFF/PE symbols to give the correct address. Previously they weren't including the image base address and the section address.

view details

Philip Craig

commit sha 3992013a6de47070184f360374942b77ae889715

Merge pull request #250 from philipc/symbol-map Replace `Symbol` with a trait

view details

push time in a month

PR merged gimli-rs/object

Replace `Symbol` with a trait

This allows users to only store the parts of the symbol that they are interested in. For example, the user may want to only store the symbol index and retrieve specific details from the symbol table only as needed.

Object::symbol_map now returns a map containing only symbol names and addresses, which is the most common use case. SymbolMap can be constructed with custom symbol entries if other information is required. This method also uses the dynamic symbol table if there are no debugging symbols.

Also fixes COFF/PE symbols to give the correct address. Previously they weren't including the image base address and the section address.

+1518 -689

0 comment

23 changed files

philipc

pr closed time in a month

push eventphilipc/object

Philip Craig

commit sha 626b520b63613bf0a69e74d04ec90db01430ae61

Replace `Symbol` with a trait This allows users to only store the parts of the symbol that they are interested in. For example, the user may want to only store the symbol index and retrieve specific details from the symbol table only as needed. `Object::symbol_map` now returns a map containing only symbol names and addresses, which is the most common use case. `SymbolMap` can be constructed with custom symbol entries if other information is required. This method also uses the dynamic symbol table if there are no debugging symbols. Also fixes COFF/PE symbols to give the correct address. Previously they weren't including the image base address and the section address.

view details

push time in a month

issue commentgimli-rs/object

Implement relocations for dynamic symbols in elf

@matprec How far did you get with this? I'm close to merging a PR (#250) that is probably going to conflict with whatever work you had done. If you no longer have time to work on this, then I would be happy to finish it off, if you can publish a branch with what you have done.

matprec

comment created time in a month

delete branch philipc/addr2line

delete branch : issue-192

delete time in a month

push eventgimli-rs/addr2line

Philip Craig

commit sha a8838d85d6bd0f103fe224f71dda67bbf9248925

Fix handling of `DW_FORM_ref_addr` in `name_attr` We were converting the reference to a unit offset, but incorrectly continuing to use the old unit. This resulted in errors such as `OffsetOutOfBounds` or `NoEntryAtGivenOffset`.

view details

Philip Craig

commit sha 27063df8e623fb24be96fe0db21f43d56d208f66

Merge pull request #193 from philipc/issue-192 Fix handling of `DW_FORM_ref_addr` in `name_attr`

view details

push time in a month

PR merged gimli-rs/addr2line

Fix handling of `DW_FORM_ref_addr` in `name_attr`

We were converting the reference to a unit offset, but incorrectly continuing to use the old unit. This resulted in errors such as OffsetOutOfBounds or NoEntryAtGivenOffset.

Fixes #192 (cc @SWW13)

+10 -7

1 comment

1 changed file

philipc

pr closed time in a month

issue closedgimli-rs/addr2line

OffsetOutOfBounds on C++ binaries

For C++ binaries with classes I get OffsetOutOfBounds errors, which most likely originate from addr2line.

Steps to reproduce:

$ cargo install addr2line --example addr2line
$ addr2line --functions --exe test-ooob 0x1172
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: OffsetOutOfBounds', /path/.cargo/registry/src/github.com-1ecc6299db9ec823/addr2line-0.13.0/examples/addr2line.rs:183:53
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The binaries seem to be fine, at least binutils works fine on them:

$ /usr/bin/addr2line --functions --exe test-ooob 0x1172 # 
_ZN9SomeClass4mainEv
/path/builddir/../test-ooob.cpp:14
$ /usr/bin/addr2line --version
GNU addr2line (GNU Binutils) 2.35

gimli also seems to have to problems finding the debug info:

$ cargo install gimli --example dwarfdump
$ dwarfdump test-ooob
< 2><0x000023af>      DW_TAG_subprogram
                        DW_AT_external              yes
                        DW_AT_name                  main
                        DW_AT_decl_file             0x00000029 /path/builddir/../test-ooob.cpp
                        DW_AT_decl_line             0x00000009
                        DW_AT_decl_column           0x00000007
                        DW_AT_linkage_name          _ZN9SomeClass4mainEv
                        DW_AT_accessibility         DW_ACCESS_public
                        DW_AT_declaration           yes
                        DW_AT_object_pointer        0x000023c0<.debug_info+0x000024e5>

Attached sources, to build them run:

$ meson builddir/
$ cd builddir/
$ ninja
$ file test-*

example.zip


Additional info:

$ rustc --version
rustc 1.46.0 (04488afe3 2020-08-24)
$ cargo --version
cargo 1.46.0 (149022b1d 2020-07-17)
$ uname -a
Linux $HOST 5.8.10-arch1-1 #1 SMP PREEMPT Thu, 17 Sep 2020 18:01:06 +0000 x86_64 GNU/Linux
$ g++ --version
g++ (GCC) 10.2.0

On a side note, by further reducing the example I found another error, which is likely related:

$ addr2line --functions --exe test-neago 0x1122
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NoEntryAtGivenOffset', /path/.cargo/registry/src/github.com-1ecc6299db9ec823/addr2line-0.13.0/examples/addr2line.rs:183:53

$ addr2line --functions --exe test-neago 0x1122
_ZN9SomeClass4mainEv
/path/builddir/../test-neago.cpp:9

closed time in a month

SWW13

issue commentgimli-rs/addr2line

OffsetOutOfBounds on C++ binaries

gimli also seems to have to problems finding the debug info:

$ cargo install gimli --example dwarfdump $ dwarfdump test-ooob < 2><0x000023af> DW_TAG_subprogram DW_AT_external yes DW_AT_name main DW_AT_decl_file 0x00000029 /path/builddir/../test-ooob.cpp DW_AT_decl_line 0x00000009 DW_AT_decl_column 0x00000007 DW_AT_linkage_name _ZN9SomeClass4mainEv DW_AT_accessibility DW_ACCESS_public DW_AT_declaration yes DW_AT_object_pointer 0x000023c0<.debug_info+0x000024e5>

Is that the full output you are getting? I wasn't able to reproduce any problem here (I get all the output that I would expect). Note that I'm using g++ 9.3.0 though.

SWW13

comment created time in a month

PR opened gimli-rs/addr2line

Fix handling of `DW_FORM_ref_addr` in `name_attr`

We were converting the reference to a unit offset, but incorrectly continuing to use the old unit. This resulted in errors such as OffsetOutOfBounds or NoEntryAtGivenOffset.

Fixes #192 (cc @SWW13)

+10 -7

0 comment

1 changed file

pr created time in a month

push eventphilipc/addr2line

Philip Craig

commit sha a8838d85d6bd0f103fe224f71dda67bbf9248925

Fix handling of `DW_FORM_ref_addr` in `name_attr` We were converting the reference to a unit offset, but incorrectly continuing to use the old unit. This resulted in errors such as `OffsetOutOfBounds` or `NoEntryAtGivenOffset`.

view details

push time in a month

create barnchphilipc/addr2line

branch : issue-192

created branch time in a month

issue commentgimli-rs/addr2line

OffsetOutOfBounds on C++ binaries

Thanks for the detailed bug report! Both of those errors have the same cause. I'll have a fix for this soon.

SWW13

comment created time in a month

issue openedgimli-rs/object

write/elf: allow writing SHT_X86_64_UNWIND

Not sure if this should be SectionKind::Unwind or SectionKind::Elf(_) to allow other section types too.

created time in a month

issue commentbjorn3/rustc_codegen_cranelift

Linker error for postsse with lld

Great. By the way, you may have missed this in the doc for write_eh_pointer: The given size is only used for DW_EH_PE_absptr formats. So for pcrel, you should be getting the size from the format (udata4).

bjorn3

comment created time in a month

issue commentbjorn3/rustc_codegen_cranelift

Linker error for postsse with lld

The bad offsets seem to be due to the addresses in the FDEs, e.g.

00000018 000000000000001c 0000001c FDE cie=00000000 pc=0000001700000000..0d43029d100e4200
  Augmentation data:     50 0c 07 08 00 00
  DW_CFA_nop

Still looking to see where these are coming from.

bjorn3

comment created time in a month

issue commentbjorn3/rustc_codegen_cranelift

Linker error for postsse with lld

Yeah I don't think that difference should matter though. I remember older versions of something (maybe LLVM) used PROGBITS too. Is there a way I can reproduce this? I didn't see a branch with your changes.

bjorn3

comment created time in a month

issue commentbjorn3/rustc_codegen_cranelift

Linker error for postsse with lld

.eh_frame needs SHF_ALLOC, could be related. The relocations themselves seem ok.

bjorn3

comment created time in a month

push eventphilipc/object

Philip Craig

commit sha 4299e27e3c26d32d9c3282e76705d43f15469636

Replace `Symbol` with a trait This allows users to only store the parts of the symbol that they are interested in. For example, the user may want to only store the symbol index and retrieve specific details from the symbol table only as needed. `Object::symbol_map` now returns a map containing only symbol names and addresses, which is the most common use case. `SymbolMap` can be constructed with custom symbol entries if other information is required. This method also uses the dynamic symbol table if there are no debugging symbols. Also fixes COFF/PE symbols to give the correct address. Previously they weren't including the image base address and the section address.

view details

push time in a month

PR opened gimli-rs/object

Replace `Symbol` with a trait

This allows users to only store the parts of the symbol that they are interested in. For example, the user may want to only store the symbol index and retrieve specific details from the symbol table only as needed.

Object::symbol_map now returns a map containing only symbol names and addresses, which is the most common use case. SymbolMap can be constructed with custom symbol entries if other information is required. This method also uses the dynamic symbol table if there are no debugging symbols.

Also fixes COFF/PE symbols to give the correct address. Previously they weren't including the image base address and the section address.

+1515 -689

0 comment

23 changed files

pr created time in a month

push eventphilipc/object

Philip Craig

commit sha 3c6b1374218db4941f369471d2366444c3ffe2c9

Replace `Symbol` with a trait This allows users to only store the parts of the symbol that they are interested in. For example, the user may want to only store the symbol index and retrieve specific details from the symbol table only as needed. `Object::symbol_map` now returns a map containing only symbol names and addresses, which is the most common use case. `SymbolMap` can be constructed with custom symbol entries if other information is required. This method also uses the dynamic symbol table if there are no debugging symbols. Also fixes COFF/PE symbols to give the correct address. Previously they weren't including the image base address and the section address.

view details

push time in a month

create barnchphilipc/object

branch : symbol-map

created branch time in a month

push eventgimli-rs/addr2line

Vivek Jain

commit sha f1845d128e7cdb9e98fb8ec1c39743f766e25e5e

Handle older DWARF versions better DWARF version <= 4 may not have index 0. As a workaround, we add a dummy value, which should be fine since presumably 0 index should not be referenced in any valid DWARF file <= v4. Fixes gimli-rs/addr2line#190.

view details

Philip Craig

commit sha c83114d441965e03271472ab71ab98d4fff97c2b

Merge pull request #191 from viveksjain/master Handle older DWARF versions better

view details

push time in a month

PR merged gimli-rs/addr2line

Handle older DWARF versions better

DWARF version <= 4 may not have index 0. As a workaround, we add a dummy value, which should be fine since presumably 0 index should not be referenced in any valid DWARF file <= v4. Fixes gimli-rs/addr2line#190.

+5 -1

0 comment

1 changed file

viveksjain

pr closed time in a month

issue closedgimli-rs/addr2line

Filename is empty with older DWARF version

I hit a curious issue where the line number was returned correctly yet filename was empty. From what I can gather based on debugging, this happens because of the logic in https://github.com/gimli-rs/addr2line/blob/424c80f7b658455accaa85dd17c2d76515c1fa6c/src/lib.rs#L495 combined with https://github.com/gimli-rs/gimli/blob/e046ca50e2d16ebe775a798d20ad947b7430859f/src/read/line.rs#L1246 - for my binary, comp_file ends up being empty and thus the loop terminates early. This may or may not be caused by the fact that my binary is generated with split-dwarf.

The following patch fixes the issue for me but I am not sure if it is the right fix:

diff --git a/src/lib.rs b/src/lib.rs
index a03630c..e40e485 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -490,8 +490,12 @@ where
                 sequences.sort_by_key(|x| x.start);

                 let mut files = Vec::new();
-                let mut index = 0;
                 let header = ilnp.header();
+                match header.file(0) {
+                    Some(file) => files.push(self.render_file(file, header, sections)?),
+                    None => files.push(String::from("")),  // DWARF version <= 4 may not have 0th index
+                }
+                let mut index = 1;
                 while let Some(file) = header.file(index) {
                     files.push(self.render_file(file, header, sections)?);
                     index += 1;

closed time in a month

viveksjain
PullRequestReviewEvent

issue commentgimli-rs/addr2line

Filename is empty with older DWARF version

I think the dummy value is fine and I prefer version checks to be kept within gimli.

viveksjain

comment created time in a month

issue commentgimli-rs/addr2line

Filename is empty with older DWARF version

The version check is already done in gimli (and you could argue that gimli should always return None for index 0 and DWARF <=4, but that's a separate issue).

viveksjain

comment created time in a month

issue commentgimli-rs/addr2line

Filename is empty with older DWARF version

While there's more we need to do to support split dwarf, I think that fix is a good step. Would you like to submit a PR with it?

viveksjain

comment created time in a month

issue commentgimli-rs/addr2line

Filename is empty with older DWARF version

It's ok, I've reproduced it now.

viveksjain

comment created time in a month

issue commentgimli-rs/addr2line

Filename is empty with older DWARF version

Thanks for the report! Are you able to give some minimal steps for how to reproduce this? I can probably work out how, but if you already know then that's easier.

viveksjain

comment created time in a month

issue openedimage-rs/image-tiff

Run TIFF decoder through tiff test images

Images at http://www.remotesensing.org/libtiff/images.html

created time in a month

issue commentgimli-rs/addr2line

addr2line doesn't build anymore w/ gimli/master

Right. Unless there is an immediate need, this will get fixed after releasing a new gimli version (whenever that happens).

gabrielesvelto

comment created time in 2 months

issue commentgimli-rs/gimli

no method named `as_debug_info_offset` found for struct `gimli::DebugInfoOffset`

Ah that'd be a good idea. I'm not sure if there is a way we can do that automatically though. rustdoc doesn't seem to include the example source, so we'd have to manually update the url to point to the tag for every release.

viveksjain

comment created time in 2 months

issue commentgimli-rs/gimli

no method named `as_debug_info_offset` found for struct `gimli::DebugInfoOffset`

gimli does not have a stable ABI, so you'll need to use a version of the example that matches the crate version you are using, such as https://github.com/gimli-rs/gimli/blob/0.22.0/examples/simple.rs

viveksjain

comment created time in 2 months

push eventgimli-rs/gimli

Nikita Baksalyar

commit sha 2421d01c9a3395cfb95537954b24f6fe8317d94e

Add a name_to_register routine to convert names into register numbers

view details

Philip Craig

commit sha e046ca50e2d16ebe775a798d20ad947b7430859f

Merge pull request #532 from nbaksalyar/convert-string-into-register Add a name_to_register routine to convert names into register numbers

view details

push time in 2 months

PR merged gimli-rs/gimli

Add a name_to_register routine to convert names into register numbers

This PR adds a converse of register_name, i.e. a function that converts a string register name into a register number. It's useful for debugger command-line interfaces.

Please let me know if this needs a test case.

+10 -0

1 comment

1 changed file

nbaksalyar

pr closed time in 2 months

PullRequestReviewEvent

Pull request review commentgimli-rs/gimli

Add a name_to_register routine to convert names into register numbers

 macro_rules! registers {                     _ => return None,                 }             }++	    /// Converts a register name into a register number.+	    pub fn name_to_register(value: &'static str) -> Option<Register> {
	    pub fn name_to_register(name: &str) -> Option<Register> {
nbaksalyar

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

issue commentgimli-rs/gimli

Updating an existing location list from .debug_loc

There's currently very little ability to mutate the debug info, but adding the ability to do so would be welcome. (#374 is a similar problem.)

vaibspider

comment created time in 2 months

pull request commentgimli-rs/object

write/elf: Check symbol.weak before symbol.is_undefined()

Sure, done.

bjorn3

comment created time in 2 months

created taggimli-rs/object

tag0.21.1

A unified interface for reading and writing object file formats

created time in 2 months

delete branch philipc/object

delete branch : release

delete time in 2 months

push eventgimli-rs/object

Philip Craig

commit sha 68063593aa2630337a9bb0ca46472d187764fd64

Bump version to 0.21.1

view details

Philip Craig

commit sha f727066485e6cffef2dd162f3c35ea2a24928480

Merge pull request #249 from philipc/release Bump version to 0.21.1

view details

push time in 2 months

PR merged gimli-rs/object

Bump version to 0.21.1
+1 -1

0 comment

1 changed file

philipc

pr closed time in 2 months

PR opened gimli-rs/object

Bump version to 0.21.1
+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchphilipc/object

branch : release

created branch time in 2 months

pull request commentm4b/goblin

pe: add basic validations

Are you trying to reproduce the error with rust 1.36? That error is in the build for the Minimum Supported Rust Version (MSRV).

Evian-Zhang

comment created time in 2 months

issue openedgimli-rs/object

write/coff: support for weak symbols seems wrong

The PE file format specifies that weak symbols should have an auxiliary record: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#auxiliary-format-3-weak-externals

Additionally, we don't emit undefined weak symbols, and I'm not sure what these should look like. This is similar to a bug for ELF (#247).

created time in 2 months

push eventgimli-rs/object

bjorn3

commit sha 0d953344c30a425d51800e88f27a14777624403c

write/elf: Check symbol.weak before symbol.is_undefined()

view details

Philip Craig

commit sha e052af5f3df87c3bbd07a957224aeb741813387c

Merge pull request #247 from bjorn3/elf_write_weak_fix write/elf: Check symbol.weak before symbol.is_undefined()

view details

push time in 2 months

more