Gprof and multithread
Hallo,Anyone knows if the last version of gprof works regularly with multithreaded applications? ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5448] New: Weak functions support is broken.
Weak symbols resolution is always done at compile time. If symbol is not known
at compile time, its address is silently assumed 0. Example:
bar.c:
#pragma weakfoo
extern voidfoo(char *);
int main(){
foo("Test.\n");
return 0;
}
$gcc -o bar bar.c
$objdump -x bar | grep foo
w *UND* foo
$objdump -R bar
bar: file format elf32-i386
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
080494e8 R_386_GLOB_DAT__gmon_start__
080494f8 R_386_JUMP_SLOT __gmon_start__
080494fc R_386_JUMP_SLOT __libc_start_main
$objdump -D bar
...08048314 :
8048314: 8d 4c 24 04 lea0x4(%esp),%ecx
8048318: 83 e4 f0and$0xfff0,%esp
804831b: ff 71 fcpushl 0xfffc(%ecx)
804831e: 55 push %ebp
804831f: 89 e5 mov%esp,%ebp
8048321: 51 push %ecx
8048322: 83 ec 04sub$0x4,%esp
8048325: c7 04 24 00 84 04 08movl $0x8048400,(%esp)
804832c: e8 cf 7c fb f7 call 0 <_init-0x8048230>
8048331: b8 00 00 00 00 mov$0x0,%eax
8048336: 83 c4 04add$0x4,%esp
8048339: 59 pop%ecx
804833a: 5d pop%ebp
804833b: 8d 61 fclea0xfffc(%ecx),%esp
804833e: c3 ret
804833f: 90 nop
...
So, as there is no entry for foo in dynamic relocation table, call is always
done at static address 0.
But the SUN Solaris 9 linker produces:
$objdump -R bar.sparc
bar.sparc: file format elf32-big
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
000106c8 UNKNOWN foo
000106cc UNKNOWN foo
000106d4 UNKNOWN foo
000106d8 UNKNOWN foo
00020810 UNKNOWN _Jv_RegisterClasses
00020818 UNKNOWN __deregister_frame_info
00020814 UNKNOWN __register_frame_info
000209a8 UNKNOWN _environ
0002084c UNKNOWN atexit
00020858 UNKNOWN exit
00020864 UNKNOWN _exit
00020870 UNKNOWN __deregister_frame_info
0002087c UNKNOWN __register_frame_info
00020888 UNKNOWN _Jv_RegisterClasses
00020894 UNKNOWN printf
So, on Linux system preloading (via LD_PRELOAD) library with defined symbol
doesn't work, but on Solaris (using SUN ld) everything works.
Even this program works as expected:
-
#pragma weakfoo
extern voidfoo(char *);
void bar(char * path)
{
void (* fptr)(char *);
if ((fptr = foo) != 0)
(* fptr)(path);
}
-
But GNU ld always loads 0 to fptr...
--
Summary: Weak functions support is broken.
Product: binutils
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: alex at alemate dot ru
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=5448
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/31948] New: aarch64: binutils does not include FEAT_CSSC in Armv8.9
https://sourceware.org/bugzilla/show_bug.cgi?id=31948
Bug ID: 31948
Summary: aarch64: binutils does not include FEAT_CSSC in
Armv8.9
Product: binutils
Version: 2.42
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: alex at alexrp dot com
Target Milestone: ---
Repro:
$ aarch64-linux-gnu-as --version
GNU assembler (GNU Binutils) 2.42
$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (GCC) 14.1.0
$ cat test.c
int ctz(unsigned int x) { return __builtin_ctz(x); }
$ aarch64-linux-gnu-gcc -march=armv8.9-a test.c
/tmp/ccTqWg96.s: Assembler messages:
/tmp/ccTqWg96.s:14: Error: selected processor does not support `ctz w0,w0'
I initially thought that this might be a GCC bug. But according to the Arm
manual, FEAT_CSSC is mandatory from Armv8.9 if FEAT_AdvSIMD is present, and GCC
considers armv8.9-a (really, armv8-a+) to have AdvSIMD unless the user
indicates otherwise. Checking include/opcode/aarch64.h in binutils, the same
seems to be true here. Yet, binutils notably does not include CSSC in
AARCH64_ARCH_V8_9A_FEATURES. I tried adding it to that macro in my local build
and the sample above built successfully.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/24644] New: OOM-Bug in _bfd_archive_64_bit_slurp_armap in bfd/archive64.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24644 Bug ID: 24644 Summary: OOM-Bug in _bfd_archive_64_bit_slurp_armap in bfd/archive64.c Product: binutils Version: 2.33 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: alex at forallsecure dot com Target Milestone: --- Created attachment 11819 --> https://sourceware.org/bugzilla/attachment.cgi?id=11819&action=edit Input to reproduce _bfd_archive_64_bit_slurp_armap reads nsymz from the archive, which is user controller. It then attempts to allocate an amount derived from nsymz, which allows attackers to trigger excessive memory consumption. I'm attaching a minimized input that triggers that issue. You can observe the behavior with `ltrace ./objdump -x ./input 2>&1 | grep malloc` or by compiling objdump with ASAN which produces the following stacktrace: ==39959==ERROR: AddressSanitizer: requested allocation size 0xa0a0a0a0a0a0a18 (0xa0a0a0a0a0a1a18 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x100 (thread T0) #0 0x49665d in __interceptor_malloc /b/swarming/w/ir/k/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:145:3 #1 0x1148578 in _objalloc_alloc /fas/apr/binutils-gdb/build-libfuzzer/libiberty/../../libiberty/objalloc.c:143:22 #2 0x7f91d9 in bfd_alloc /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/opncls.c:949:9 #3 0x7f8381 in bfd_zalloc /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/opncls.c:998:9 #4 0x10c1636 in _bfd_archive_64_bit_slurp_armap /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/archive64.c:98:39 #5 0x7d90c6 in bfd_slurp_armap /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/archive.c:1149:14 #6 0x7d8a84 in bfd_generic_archive_p /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/archive.c:875:8 #7 0x7f0da6 in bfd_check_format_matches /fas/apr/binutils-gdb/build-libfuzzer/bfd/../../bfd/format.c:315:14 - binutils version: commit 12efd68d159444ad8dfe24e49965a228ba980b86 (Wed Jun 5 2019) - OS: Ubuntu 18.04.2, running in a docker container on Mac OS - Linux 4.9.125-linuxkit - clang version 9.0.0 Found using ForAllSecure's Mayhem. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24644] OOM-Bug in _bfd_archive_64_bit_slurp_armap in bfd/archive64.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24644 --- Comment #2 from Alex Rebert --- Oops. Sorry about that. I saw https://sourceware.org/bugzilla/show_bug.cgi?id=23361 and thought you were interested in those. FWIW, there are a few overflows in there, and the overflow checks don't catch them all. I haven't been able to make it crash yet, but I have an input that leads to calling bfd_bread on a small buffer with a very large size. Happy to upload it if you're interested in it. Details: When parsed_size=-1 and nsymz=2, the function allocates a 8-byte symdefs array, while stringsize is 18446744073709551591). Since bfd_read calls cache_bread, which takes a signed size which ends up being negative, no overflow happens. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11960] New: objdump gets the wrong length for pushw immediate in 64 bit mode
In 64 bit code, objdump misunderstands the pushw immediate instruction. I believe the disassembly for this example should be: "pushw $0x", followed by whatever junk for the 0xaa and 0xbb bytes. The disassembler is eating two extra bytes and displaying a 64 bit value instead of a 16 bit one. example: $ cat pushw.s .text pushw $0x .byte 0xaa .byte 0xbb $ as -o pushw.o pushw.s $ objdump -d pushw.o pushw.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 66 68 22 22 aa bb pushw $0xbbaa $ I found the same behavior with these versions: 2.19.51.0.14-3.fc11 20090722 2.20.1.20100303 -- Summary: objdump gets the wrong length for pushw immediate in 64 bit mode Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: alex at cloudswitch dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=11960 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
