GNU Property notes are different from normal notes because they use
variable alignment/padding of their fields. They are 8 byte aligned,
but use 4 byte fields. The name is aligned at 4 bytes and padded so
that, the desc is aligned at 8 bytes. The whole note is padded to
8 bytes again. For normal no
There were some recent bug reports where we trusted the ELF section header
to be sane and divided the sh_size by the sh_entsize to get the number of
objects in the section. This would cause a divide by zero if the file was
corrupt and the sh_entsize was zero. Add checks for any such code.
Signed-o
After a bit more testing found one other issue.
It can happen that the section indexes in the group need to be
renumbered when eu-unstrip puts the stripped and debug file together
again. So we need to explicitly do that.commit eee4269e53154daaf0251371aacd91ec5db3eb30
Author: Mark Wielaard
Date:
On Sat, 2018-10-13 at 15:17 +0200, Mark Wielaard wrote:
> In object files there could be multiple .debug_macro sections.
> These are COMDAT sections used as imports. Note that the output for
> DW_MACRO_import isn't ideal since the offset is printed against the
> start of the .debug_macro section, b
On Sun, 2018-10-14 at 16:48 +0200, Mark Wielaard wrote:
> There were two issues when reading note data from a core file.
> We didn't check if the data we already had in a buffer was big
> enough. And if we did get the data, we should check if we got
> everything, or just a part of the data.
Pushed
https://sourceware.org/bugzilla/show_bug.cgi?id=23752
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Sun, 2018-10-14 at 16:59 +0200, Mark Wielaard wrote:
> A bogus ELF file could have sh_entsize as zero. Don't divide by zero,
> but just assume there are no entries in the section.
Pushed to master.
On Sun, 2018-10-14 at 17:31 +0200, Mark Wielaard wrote:
> If the ar header contains a bogus ar_date then in verbose mode we
> would
> get a NULL pointer from localtime. Just assume the entry was created
> during the epoch.
Pushed to master.
https://sourceware.org/bugzilla/show_bug.cgi?id=23755
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=23754
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Tue, 2018-10-16 at 14:22 +0200, Mark Wielaard wrote:
> We could end up with a negative length in a call to memchr.
Pushed to master.
https://sourceware.org/bugzilla/show_bug.cgi?id=23782
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Thu, 2018-10-18 at 19:02 +0200, Mark Wielaard wrote:
> A bogus ELF file could have sh_entsize as zero. Don't divide by zero,
> but just assume there are no symbols in the section.
Pushed to master.
https://sourceware.org/bugzilla/show_bug.cgi?id=23786
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=23787
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Fri, 2018-10-19 at 01:02 +0200, Mark Wielaard wrote:
> eu-size didn't handle an ELF ar file that contained an ar file itself
> correctly. handle_ar would recursively call itself but close the ELF
> file before returning. Only close the ELF file at the top-level.
Pushed to master.
On Fri, 2018-10-19 at 15:03 +0200, Mark Wielaard wrote:
> There were some recent bug reports where we trusted the ELF section
> header
> to be sane and divided the sh_size by the sh_entsize to get the
> number of
> objects in the section. This would cause a divide by zero if the file
> was
> corrup
17 matches
Mail list logo
