[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23919 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5f6c22aee74f17393b82934a5682d985672e011a commit 5f6c22aee74f17393b82934a5682d985672e011a Author: H.J. Lu Date: Sun Dec 2 05:42:36 2018 -0800 gold: Get alignment of uncompressed section from ch_addralign The ELF compression header has a field (ch_addralign) that is set to the alignment of the uncompressed section. This way the section itself can have a different alignment than the decompressed section. Update decompress_input_section to get alignment of the decompressed section and use it when merging decompressed strings. PR binutils/23919 * merge.cc (Output_merge_string::do_add_input_section): Get addralign from decompressed_section_contents. * object.cc (build_compressed_section_map): Set info.addralign. (Object::decompressed_section_contents): Add a palign argument and store p->second.addralign in *palign if it isn't NULL. * object.h (Compressed_section_info): Add addralign. (section_is_compressed): Add a palign argument, default it to NULL, store p->second.addralign in *palign if it isn't NULL. (Object::decompressed_section_contents): Likewise. * output.cc (Output_section::add_input_section): Get addralign from section_is_compressed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23919 H.J. Lu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #13 from H.J. Lu --- Fixed for 2.32. -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] libebl: Fix reading GNU_PROPERTY_STACK_SIZE reading from 32bit notes.
When reading a GNU_PROPERTY_STACK_SIZE we need to use the proper data
type. GElf_Addr is 64bit always and when reading a 32bit size part of
it would not be initialized. Use either Elf32_Addr or Elf64_Addr to
read and print the data.
Add 32bit and 64bit, little and big endian testcases.
Signed-off-by: Mark Wielaard
---
libebl/ChangeLog| 5 ++
libebl/eblobjnote.c | 20 --
tests/ChangeLog | 9 +++
tests/Makefile.am | 4 ++
tests/run-readelf-n.sh | 101
tests/testfile_gnu_props.32be.o.bz2 | Bin 0 -> 225 bytes
tests/testfile_gnu_props.32le.o.bz2 | Bin 0 -> 215 bytes
tests/testfile_gnu_props.64be.o.bz2 | Bin 0 -> 238 bytes
tests/testfile_gnu_props.64le.o.bz2 | Bin 0 -> 233 bytes
9 files changed, 134 insertions(+), 5 deletions(-)
create mode 100644 tests/testfile_gnu_props.32be.o.bz2
create mode 100644 tests/testfile_gnu_props.32le.o.bz2
create mode 100644 tests/testfile_gnu_props.64be.o.bz2
create mode 100644 tests/testfile_gnu_props.64le.o.bz2
diff --git a/libebl/ChangeLog b/libebl/ChangeLog
index a2f89562f..0174f331a 100644
--- a/libebl/ChangeLog
+++ b/libebl/ChangeLog
@@ -1,3 +1,8 @@
+2018-12-02 Mark Wielaard
+
+ * eblobjnte.c (ebl_object_note): For GNU_PROPERTY_STACK_SIZE use
+ an Elf32_Addr or Elf64_Addr to read and print the size.
+
2018-11-15 Mark Wielaard
* eblobjnotetypename.c (ebl_object_note_type_name): Don't update
diff --git a/libebl/eblobjnote.c b/libebl/eblobjnote.c
index 58ac86d7e..c19ea37fc 100644
--- a/libebl/eblobjnote.c
+++ b/libebl/eblobjnote.c
@@ -360,15 +360,22 @@ ebl_object_note (Ebl *ebl, uint32_t namesz, const char
*name, uint32_t type,
if (prop.pr_type == GNU_PROPERTY_STACK_SIZE)
{
printf ("STACK_SIZE ");
- if (prop.pr_datasz == 4 || prop.pr_datasz == 8)
+ union
+ {
+ Elf64_Addr a64;
+ Elf32_Addr a32;
+ } addr;
+ if ((elfclass == ELFCLASS32 && prop.pr_datasz == 4)
+ || (elfclass == ELFCLASS64 && prop.pr_datasz == 8))
{
- GElf_Addr addr;
in.d_type = ELF_T_ADDR;
out.d_type = ELF_T_ADDR;
in.d_size = prop.pr_datasz;
- out.d_size = sizeof (addr);
+ out.d_size = prop.pr_datasz;
in.d_buf = (void *) desc;
- out.d_buf = (void *) &addr;
+ out.d_buf = (elfclass == ELFCLASS32
+ ? (void *) &addr.a32
+ : (void *) &addr.a64);
if (gelf_xlatetom (ebl->elf, &out, &in,
elfident[EI_DATA]) == NULL)
@@ -376,7 +383,10 @@ ebl_object_note (Ebl *ebl, uint32_t namesz, const char
*name, uint32_t type,
printf ("%s\n", elf_errmsg (-1));
return;
}
- printf ("%#" PRIx64 "\n", addr);
+ if (elfclass == ELFCLASS32)
+ printf ("%#" PRIx32 "\n", addr.a32);
+ else
+ printf ("%#" PRIx64 "\n", addr.a64);
}
else
printf (" (garbage datasz: %" PRIx32 ")\n",
diff --git a/tests/ChangeLog b/tests/ChangeLog
index 225a51d5c..1382e40af 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,12 @@
+2018-12-02 Mark Wielaard
+
+ * testfile_gnu_props.32le.o.bz2: New testfile.
+ * testfile_gnu_props.64le.o.bz2: Likewise.
+ * testfile_gnu_props.32be.o.bz2: Likewise.
+ * testfile_gnu_props.64be.o.bz2: Likewise.
+ * Makefile (EXTRA_DIST): Add new testfiles.
+ * run-readelf-n.sh: Run tests on new testfiles.
+
2018-11-28 Mark Wielaard
* backtrace-data.c (main): Improve error message.
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 3ca0e1c22..bc8c19a63 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -278,6 +278,10 @@ EXTRA_DIST = run-arextract.sh run-arsymtest.sh run-ar.sh \
run-readelf-types.sh \
run-readelf-n.sh \
testfile-gnu-property-note.bz2 testfile-gnu-property-note.o.bz2 \
+testfile_gnu_props.32le.o.bz2 \
+testfile_gnu_props.64le.o.bz2 \
+testfile_gnu_props.32be.o.bz2 \
+testfile_gnu_props.64be.o.bz2 \
run-allfcts-multi.sh \
test-offset-loop.bz2 test-offset-loop.alt.bz2 \
run-prelink-addr-test.sh \
diff --git a/tests/run-readelf-n.sh b/tests/run-readelf-n.sh
index c2db2ce2a.
[Bug general/23914] Add --disable-werror to ./configure support (example trigger: CFLAGS=-Og
https://sourceware.org/bugzilla/show_bug.cgi?id=23914
--- Comment #4 from Sergei Trofimovich ---
(In reply to Mark Wielaard from comment #3)
> (In reply to Sergei Trofimovich from comment #2)
> > Gentoo allows users to control CC and CFLAGS and thus the space for getting
> > a warning is wide. People frequently use things like -Wcast-qual or other
> > high signal-to-noise flags for their purposes.
>
> If they do and don't care about the warnings, then why don't they simply add
> -Wno-error too?
I'm not sure it works when CFLAGS are set system-wide (instead of per-package
basis). A few packages do feature testing with -Werror set and insist on keep
doing it.
Gentoo can pass CFLAGS="-Wno-error ${USER_CFLAGS}" to elfutils package
unconditionally as part of a build script if it's a supported configuration
upstream. It should be good enough alternative to --disable-werror.
> > 2. CFLAGS="-g -O2 -Wstack-protector"
> >
> > CC readelf.o
> > readelf.c: In function 'open_input_section':
> > readelf.c:581:1: error: stack protector not protecting local variables:
> > variable length buffer [-Werror=stack-protector]
> >open_input_section (int fd)
> >^~
>
> That in itself wouldn't warn. I assume you are using
> -fstack-protector[-all|strong] too.
Ah, right. Gentoo's gcc is configured with --enable-default-ssp (#define
__SSP_STRONG__ 3). That's why enabling warning alone is enough.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libelf/23916] [bisected] elifutils-0.175 broke kernel's objtool (elifutils-0.173 works)
https://sourceware.org/bugzilla/show_bug.cgi?id=23916 --- Comment #6 from Sergei Trofimovich --- (In reply to Mark Wielaard from comment #5) > I filed a binutils bug with patch. > https://sourceware.org/bugzilla/show_bug.cgi?id=23919 > > If you are able to test patch that on your setup to see if it resolves the > issue with objtool that would be really helpful. Built kernel successfully against binutils from git master and elfutils-0.175. Boots fine and gdb can still load .ko files for debugging. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23916] [bisected] elifutils-0.175 broke kernel's objtool (elifutils-0.173 works)
https://sourceware.org/bugzilla/show_bug.cgi?id=23916 Dmitry V. Levin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-03 Ever confirmed|0 |1 --- Comment #7 from Dmitry V. Levin --- Same here. I think this bug report can be closed. -- You are receiving this mail because: You are on the CC list for the bug.
