[Bug ld/31710] New: Segmentation fault using wrapping and debug information

[roberto.vargas at midokura dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31710

Bug ID: 31710
   Summary: Segmentation fault using wrapping and debug
information
   Product: binutils
   Version: 2.43 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: roberto.vargas at midokura dot com
  Target Milestone: ---

Created attachment 15497
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15497&action=edit
Minimun test case to reproduce the problem

Hi,

I found a case where ld segfaults when a wrap is done around
a struct initialized, debug is enabled and the symbol to be
wrapped is extracted from a library:

$ uname -a
Linux nomad 6.6.27_1 #1 SMP PREEMPT_DYNAMIC Tue Apr 16 17:28:14 UTC
2024 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ ld --version
GNU ld (GNU Binutils) 2.42.50.20240507
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
$ ar --version
GNU ar (GNU Binutils) 2.42.50.20240507
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License version 3 or (at your option) any later
version.
This program has absolutely no warranty.
$ make
cc-c -o main.o main.c
cc-c -o impl.o impl.c
ar -rv lib.a impl.o
ar: creating lib.a
a - impl.o
gcc  -Wl,--wrap=impl main.o lib.a
$ make clean
rm -f *.o *.a a.out core*
$ make CFLAGS=-g
cc -g   -c -o main.o main.c
cc -g   -c -o impl.o impl.c
ar -rv lib.a impl.o
ar: creating lib.a
a - impl.o
gcc  -Wl,--wrap=impl main.o lib.a
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
compilation terminated.
make: *** [Makefile:4: main] Error 1

I executed the linker command line with a local build of binutils master
(commit 810203888da) with the same result:

$ /usr/local/x86_64-pc-linux-gnu/bin/ld --build-id --eh-frame-hdr
--hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie
/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../lib64/Scrt1.o
/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0/crtbeginS.o
-L/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0
-L/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0/../../.. --wrap=impl main.o
lib.a -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state
--as-needed -lgcc_s --pop-state
/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0/crtendS.o
/usr/lib64/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../lib64/crtn.o
Segmentation fault (core dumped)
$ gdb /usr/local/x86_64-pc-linux-gnu/bin/ld core
GNU gdb (GDB) 15.0.50.20240507-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/x86_64-pc-linux-gnu/bin/ld...
[New LWP 25976]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/local/x86_64-pc-linux-gnu/bin/ld --build-id
--eh-frame-hdr --hash-style=gn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x5564c777ba2a in elf_x86_64_relocate_section
(output_bfd=0x5564c80ba070, info=0x5564c79c4300 ,
input_bfd=0x5564c80d5d90, input_section=0x5564c8104568,
contents=0x5564c84f9df0 ,
r

[Bug ld/31710] Segmentation fault using wrapping and debug information

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31710

--- Comment #1 from Sourceware Commits  ---
The master branch has been updated by Nick Clifton :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=43bb6c0e087b6fd46c0b347d2b5678acb5c68c85

commit 43bb6c0e087b6fd46c0b347d2b5678acb5c68c85
Author: Nick Clifton 
Date:   Wed May 8 13:42:22 2024 +0100

Fix RELOC_FOR_GLOBAL_SYMBOLS macro so that it can cope with user defined
symbols that start with __wrap_.

  PR 31710

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31710] Segmentation fault using wrapping and debug information

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31710

Nick Clifton  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
Hi Roberto,

  Thanks for reporting this issue.  The problem was a bug in a macro used to 
  process relocations against global symbols. This macro assumed that a name
  lookup would always succeed and so did not check for a NULL return value.
  I have checked in a small patch to fix this problem.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Issue 66570 in oss-fuzz: binutils:fuzz_objdump_safe: Out-of-memory in fuzz_objdump_safe

[sheriffbot via monorail]

Updates:
Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded

Comment #3 on issue 66570 by sheriffbot: binutils:fuzz_objdump_safe: 
Out-of-memory in fuzz_objdump_safe
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66570#c3

This bug has exceeded our disclosure deadline. It has been opened to the public.

- Your friendly Sheriffbot

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.

[Bug ld/31710] Segmentation fault using wrapping and debug information

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31710

--- Comment #3 from Sourceware Commits  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1509f0c231854b2fd3556d77d6be1f98301bf8a3

commit 1509f0c231854b2fd3556d77d6be1f98301bf8a3
Author: H.J. Lu 
Date:   Wed May 8 06:22:20 2024 -0700

ld: Add PR ld/31710 tests

PR ld/31710
* testsuite/ld-elf/wrap.exp: Run ld/31710 tests.
* testsuite/ld-elf/wrap2.h: New file.
* testsuite/ld-elf/wrap2a.c: Likewise.
* testsuite/ld-elf/wrap2b.c: Likewise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31714] New: Static function pointer

[Senthilkumar.PR at elektrobit dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31714

Bug ID: 31714
   Summary: Static function pointer
   Product: binutils
   Version: 2.35
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: Senthilkumar.PR at elektrobit dot com
  Target Milestone: ---

Created attachment 15501
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15501&action=edit
Zip folder contains snippet and preprocessed *.c files

Hi,

I am using compiler v10.2 (v10.2_build_b1728_g5963bc8).

GNU ld (GNU Binutils build.sh rev=g5963bc8 s=F1020 -i /opt/freescale Earmv7nGCC
-V release_g5963bc8_build_Fed_Earmv7nGCC (BLD = 1728)) 2.35

I observed some suspicious behavior in Linking.

In my code, I have a static function with the same name in three different
files (Task1.c, Task2.c, and Task3.c). The static function is accessed through
a static volatile function pointer in respective files. The volatile qualifier
is added to avoid optimization. Each file has its own dedicated data section in
memory.

With nxp gcc v10.2 and binutils 2.35, I observed that the data section for all
static variables of Task2 file is initialized properly, but not for the other
files (Task1 and Task3).

As a result, our code crashes when the static function is accessed through the
static function pointer.

Reason: The static function pointer has an invalid address or is "0".

Our observation: When we moved to a higher version of gcc (i.e., v10.3 with
binutils v2.36), this issue is not observed.

Kindly let us know if this issue is already known. If yes, could you please let
us know the right patch version for v2.35? Otherwise, this needs to be fixed in
v2.35.

Upgrading to the v10.3 toolchain is not within our project scope.

I have attached all files and snippets for your reference.

Note: I am working on SRAM; no flash is used, hence no data copy operation.

We used same options for both toolchain version. Except linker option
-specs=nano.specs, this is not used for v10.3 with binutils v2.36


Compiler Option:

-mcpu=cortex-m7 
-mthumb
-mlittle-endian
-mfpu=fpv5-sp-d16
-mfloat-abi=hard
-std=c99
-Os
-ggdb3
-Wall
-Wextra
-pedantic
-Wstrict-prototypes
-Wundef
-Wunused
-Werror=implicit-function-declaration
-Wsign-compare
-Wdouble-promotion
-fno-short-enums
-funsigned-char
-funsigned-bitfields
-fomit-frame-pointer
-fno-common
-fstack-usage
-fdump-ipa-all
-c
--sysroot=$(NEWLIB_DIR)
-specs=nano.specs
-specs=nosys.specs

Assembler Option:

-xassembler-with-cpp
-mcpu=cortex-m7
-mfpu=fpv5-sp-d16
-mfloat-abi=hard
-mthumb
-c

Linker Option:

--entry=$(ENTRYSYMBOL)
-nostartfiles
-mcpu=cortex-m7
-mthumb
-mfpu=fpv5-sp-d16
-mfloat-abi=hard
-mlittle-endian
-ggdb3
-lc
-lm
-lgcc
-specs=nano.specs
-specs=nosys.specs
--sysroot=$(LIB_DIR)


With Regards,

Manjunath Bhavimani

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31714] Static function pointer

[Senthilkumar.PR at elektrobit dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31714

--- Comment #1 from Bhavimani, Manjunath  ---
Created attachment 15502
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15502&action=edit
Command to build .asm .o .elf

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31714] Static function pointer

[Senthilkumar.PR at elektrobit dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31714

Bhavimani, Manjunath  changed:

   What|Removed |Added

 Target||arm-none-eabi
  Build||GNU Binutils build.sh
   ||rev=g5963bc8 s=F1020 -i
   ||/opt/freescale Earmv7nGCC
   ||-V
   ||release_g5963bc8_build_Fed_
   ||Earmv7nGCC (BLD = 1728)

-- 
You are receiving this mail because:
You are on the CC list for the bug.