gcc undefined sanitizer flags:
elf_begin.c:230:18: runtime error: member access within misaligned
address 0xf796400a for type 'struct Elf64_Shdr', which requires 4 byte
alignment struct.
This seems a wrong warning since we aren't accessing the field member
of the struct, but are taking the addres
* Mark Wielaard:
> This seems a wrong warning since we aren't accessing the field member
> of the struct, but are taking the address of it. But we can do the
> same by adding the field offsetof to the base address. Which doesn't
> trigger a runtime error.
I think the warning is correct. I believ
dwfl_link_map_report can only handle program headers that are the
correct (32 or 64 bit) size. The buffer read in needs to contain room
for at least one Phdr.
https://sourceware.org/bugzilla/show_bug.cgi?id=28660
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog | 6 ++
libdwfl/link_map.
https://sourceware.org/bugzilla/show_bug.cgi?id=28660
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
Hi,
On Thu, Dec 09, 2021 at 06:35:14AM -0500, Frank Ch. Eigler via Elfutils-devel
wrote:
> > x32, riscv32, arc use 64bit time_t even while they are 32bit
> > architectures, therefore directly using integer printf formats will not
> > work portably.
>
> > Use a plain long everywhere as the interv
https://sourceware.org/bugzilla/show_bug.cgi?id=28660
--- Comment #6 from Evgeny Vereshchagin ---
Thanks! I can confirm that the issue is gone.
I tested it in https://github.com/evverx/elfutils/pull/53 by adding that file
to the testsuite in
https://github.com/evverx/elfutils/pull/53/commits/38c
The Buildbot has detected a new failure on builder elfutils-centos-x86_64 while
building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/1/builds/884
Buildbot URL: https://builder.wildebeest.org/buildbot/
Worker for this Build: centos-x86_64
Build
https://sourceware.org/bugzilla/show_bug.cgi?id=28660
--- Comment #7 from Evgeny Vereshchagin ---
> Interestingly, something started to trigger unreproducible MSan crashes but
> I'm inclined to say it was probably a fluke.
It wasn't a glitch. The file I added to the test suite was also automatic