platform_external_elfutils/src/readelf.c, branch brillo-m7-dev

Trust AC_SYS_LARGEFILE to provide large file support

2015-10-09T17:10:37+00:00

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 explicit 64-bit names, which won't work on platforms
like FreeBSD where off_t is always 64-bit and there are no foo64 names.
It's better to just trust that AC_SYS_LARGEFILE is doing it correctly.

But we can verify this too, as some file could easily forget to include
config.h.  The new tests/run-lfs-symbols.sh checks all build targets
against lfs-symbols (taken from lintian) to make sure everything was
implicitly mapped to 64-bit variants when _FILE_OFFSET_BITS is set.

Signed-off-by: Josh Stone

Do without union of variable length arrays.

2015-10-07T20:44:41+00:00

Prepare to compile with clang.

A union like
  { T32 a32[n]; T64 a64[n]; } u;
is expanded to
  size_t nbytes = n * MAX(sizeof(T32), sizeof(T64));
  void *data = malloc(nbytes);
  T32 (*a32)[n] = data;
  T64 (*a64)[n] = data;

Signed-off-by: Chih-Hung Hsieh

Initialize variable before use.

2015-09-10T12:02:24+00:00

Some compiler does not know that error function never returns.

Signed-off-by: Chih-Hung Hsieh

Replace printf %Z length modifier with %z.

2015-09-07T13:04:22+00:00

%Z is a GNU extension predating the ISO C99 %z modifier supported by
libc5 and no longer recommended.

Signed-off-by: Chih-Hung Hsieh 
Signed-off-by: Mark Wielaard

readelf: handle_core_item large right shift triggers undefined behaviour.

2015-09-03T08:50:58+00:00

The problem is this:

  int n = ffs (w);
  w >>= n;

The intent is to shift away up to (and including) the first least
significant bit in w. But w is an unsigned int, so 32 bits. And the
least significant bit could be bit 32 (ffs counts from 1). Unfortunately
a right shift equal to (or larger than) the length in bits of the left
hand operand is undefined behaviour. We expect w to be zero afterwards.
Which would terminate the while loop in the function. But since it is
undefined behaviour anything can happen. In this case, what will actually
happen is that w is unchanged, causing an infinite loop...

gcc -fsanitize=undefined will catch and warn about this when w = 0x80000000

https://bugzilla.redhat.com/show_bug.cgi?id=1259259

Signed-off-by: Mark Wielaard

readelf: Make sure phdr2_mem lifetime/scope equals phdr2 pointer.

2015-06-19T11:10:22+00:00

We dont' want GCC to dispose or reuse phdr2_mem stack memory while phdr2
is pointing to it.

Signed-off-by: Mark Wielaard

readelf: Don't leak memory on failure path in handle_gnu_hash.

2015-06-19T11:08:43+00:00

Signed-off-by: Mark Wielaard

readelf: Fix cie_offset calculation comparison on 32bit.

2015-04-28T12:14:09+00:00

gcc -fsanitize=undefined pointed out that on 32bit systems the calculation
to match the cie_offset to the cie_id could be undefined because a cie_id
could be an unsigned 64bit value while ptrdiff_t is only 32bits. Correct
the calculation to use 64bit values.

Signed-off-by: Mark Wielaard

readelf: Check all offsets used in print_gdb_index_section against d_size.

2015-04-28T11:57:29+00:00

https://bugzilla.redhat.com/show_bug.cgi?id=1170810#c29

Signed-off-by: Mark Wielaard

readelf: Always try to print some debug section information.

2015-04-28T11:55:35+00:00

Even if we cannot create a proper Dwarf dbg we can still print the
information of various debug sections. All all debug print section
functions already check first they can access the appropriate data.

Signed-off-by: Mark Wielaard