Re: as aborts after buffer overflow
Hi Peter, gcc -c -O1 -ggdb -masm=intel -Wa,-acdhlgn=gfp_library.lst -Wa,-- listing-lhs-width=4,--listing-rhs-width=132 -o gfp_library.o gfp_library.c In the future if you have other bugs like this to report, please could you capture the compiler's assembler output and provide that as the test file, rather than the C source ? The reason being that this eliminates one step in the process and it means that I do not need to have exactly the same version of gcc installed on my machine. Also - it really helps if you can file a bug report with the binutils bugzilla system: https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils This lets us track the bug and any discussion about it. Plus we can put comments in the code referring to the bug's PR number and even create new tests that refer back to the bug report as well. As it happens however I am able to reproduce the problem locally, and the first thing that occurs to be is to wonder why you are capturing an assembler listing ? And given that it is needed, why do you need a limit on the width of the source code in the listing ? The problem is obviously in the listing code, which is old and crufty. I am taking a look however and I may be able to find a solution. Cheers Nick
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #13 from Dan McDonald --- (In reply to Nick Clifton from comment #12) > Hi Dan, > > I do not know if it will help, but you can work around the problem by using > the -j option to explicitly request the disassembly of the sections that > matter, eg: > > objdump -Dz 23.4-strap-libv8_base.a -j .bss.v8dbg_SmiTag -j > .data.v8dbg_SmiTagMask > This workaround will not help as there are (lemme check) 85 symbols that get dropped generating a .h file because of this. The big .a file is fed into a pipeline that wants all of the zeroed data sections (which get marked as .bss) and the non-zeroed ones (that get marked as .data). I am going to enable `-fno-zero-initialized-in-bss` and see if that helps my situation, and will report here with an update. Did this change in 2.41 include updates in the man page or other user documentation? If so, sorry for missing it. If not, that may be misleading to folks beyond me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from H.J. Lu --- Which version of binutils's objdump -z -D dumps a .bss section? Please show the output of such objdump -z -D on x.o. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #6 from Dan McDonald --- root@ubuntu-22:~# cat x.s .text foo: .zero 10 mov %eax, %ebx root@ubuntu-22:~# gcc -c x.s root@ubuntu-22:~# file x.o x.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped root@ubuntu-22:~# objdump --version GNU objdump (GNU Binutils for Ubuntu) 2.38 Copyright (C) 2022 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. root@ubuntu-22:~# objdump -z -D x.o x.o: file format elf64-x86-64 Disassembly of section .text: : 0: 00 00 add%al,(%rax) 2: 00 00 add%al,(%rax) 4: 00 00 add%al,(%rax) 6: 00 00 add%al,(%rax) 8: 00 00 add%al,(%rax) a: 89 c3 mov%eax,%ebx root@ubuntu-22:~# as -mx86-used-note=no -o x2.o x.s root@ubuntu-22:~# objdump -z -D x2.o x2.o: file format elf64-x86-64 Disassembly of section .text: : 0: 00 00 add%al,(%rax) 2: 00 00 add%al,(%rax) 4: 00 00 add%al,(%rax) 6: 00 00 add%al,(%rax) 8: 00 00 add%al,(%rax) a: 89 c3 mov%eax,%ebx root@ubuntu-22:~# -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #12 from Nick Clifton --- Hi Dan, Sorry, you are right, I was wrong. And now that I understand the problem I have been able to track down the exact commit that causes this issue: 0a3137ce4c4b Which states: There is some inconsistency between the behaviour of objdump -D and objdump -s, both supposedly operating on all sections by default. objdump -s ignores bss sections, while objdump -D dissassembles the zeros. Fix this by making objdump -D ignore bss sections too. I do not know if it will help, but you can work around the problem by using the -j option to explicitly request the disassembly of the sections that matter, eg: objdump -Dz 23.4-strap-libv8_base.a -j .bss.v8dbg_SmiTag -j .data.v8dbg_SmiTagMask Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
as aborts after buffer overflow
Dear,
compiling the attached example fails with this error message:
*** buffer overflow detected ***: terminated
/tmp/ccyb3JRr.s: Assembler messages:
/tmp/ccyb3JRr.s: Internal error (Aborted).
Please report this bug.
Environment:
$ uname -a
Linux gygv 6.10.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 12
18:26:09 UTC 2024 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
Copyright (C) 2024 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.
$ as --version
GNU assembler version 2.41-37.fc40
Copyright (C) 2023 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 later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-redhat-linux'.
The command line is this:
gcc -c -O1 -ggdb -masm=intel -Wa,-acdhlgn=gfp_library.lst -Wa,--
listing-lhs-width=4,--listing-rhs-width=132 -o gfp_library.o
gfp_library.c
There are a number of ways to get it compiled: -O0 instead of -O1, or
omitting ,--listing-rhs-width=132, or omittig -ggdb, or eliminating
the get_realloc() function and replacing its call with its return
expression in the caller.
But the problem is that such solutions don't always work: the original
gfp_library.c is more complex and the simple solution of using -O0
didn't help.
br
PK
#include
#define LIBC "/usr/lib64/libc.so.6"
typedef void *realloc_ft(void *, size_t);
static void *libc_so;
static realloc_ft *libc_realloc;
static realloc_ft *get_realloc( void )
{
return (realloc_ft *)dlsym(libc_so, "realloc");
}
int gfp_lib_init( void )
{
if ((libc_so = dlopen(LIBC, RTLD_LAZY)) == 0 ||
(libc_realloc = get_realloc()) == 0)
return 1;
else
return 0;
}
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #7 from Nick Clifton --- Hi Dan, (In reply to Dan McDonald from comment #3) > Run it on the provided sample files. There appears to be a problem with one of the grep command line options that you are using... I tried running one of the commands by hand and it failed, just as you are reporting: $ objdump -z -D 23.4-strap-libv8_base.a | grep -qw v8dbg_SmiTag $ echo $? 1 So I tried removing the options from grep to see if it found anything: $ objdump -z -D 23.4-strap-libv8_base.a | grep v8dbg_SmiTag Disassembly of section .data.v8dbg_SmiTagMask: : $ echo $? 0 The most likely culprit was the word option, so I restored that: $ objdump -z -D 23.4-strap-libv8_base.a | grep -w v8dbg_SmiTag $ echo $? 1 And just to confirm, if you have -q without -w, the test does still work: $ objdump -z -D 23.4-strap-libv8_base.a | grep -q v8dbg_SmiTag $ echo $? 0 > Also, is it possible that the combination of "-z -D" might be the problem? It is very unlikely. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #9 from Dan McDonald --- Adding a tiny C program and an a.out it generated on the Ubuntu 22 box I've been using to further demonstrate on a smaller level. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #11 from Dan McDonald --- Created attachment 15719 --> https://sourceware.org/bugzilla/attachment.cgi?id=15719&action=edit a.out from the C program, compiled on Ubuntu 22 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #10 from Dan McDonald --- Created attachment 15718 --> https://sourceware.org/bugzilla/attachment.cgi?id=15718&action=edit Small C program that could compile an object with the same properties as the big .a files. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from H.J. Lu --- [hjl@gnu-tgl-3 tmp]$ cat x.s .bss foo: .zero 10 [hjl@gnu-tgl-3 tmp]$ as -mx86-used-note=no -o x.o x.s [hjl@gnu-tgl-3 tmp]$ objdump -z -D x.o x.o: file format elf64-x86-64 [hjl@gnu-tgl-3 tmp]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32191] --rosegment places .note.gnu.property in executable PT_LOAD segment for -z separate-code
https://sourceware.org/bugzilla/show_bug.cgi?id=32191 --- Comment #1 from Sourceware Commits --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=052940eba6fcd2b9f359f03ee205e9cd4dfb1575 commit 052940eba6fcd2b9f359f03ee205e9cd4dfb1575 Author: H.J. Lu Date: Fri Sep 20 11:32:26 2024 +0800 ld: Ignore .note.gnu.build-id when placing orphaned notes The commits: e8e10743f7b Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map place .note.gnu.build-id before text sections when --rosegment is used. Ignore .note.gnu.build-id when placing orphaned notes if --rosegment and -z separate-code are used together to avoid putting any note sections between .note.gnu.build-id and text sections in the same PT_LOAD segment. PR ld/32191 * ldlang.c (lang_insert_orphan): Ignore .note.gnu.build-id when placing orphaned notes. * testsuite/ld-elf/pr23658-1a.d: Pass --no-rosegment to ld. * testsuite/ld-elf/pr23658-1c.d: Likewise. * testsuite/ld-elf/pr23658-1e.d: New file. * testsuite/ld-elf/pr23658-1f.d: Likewise. * testsuite/ld-i386/i386.exp: Run PR ld/32191 test. * testsuite/ld-i386/pr32191.d: New file. * testsuite/ld-x86-64/lam-u48.rd: Updated. * testsuite/ld-x86-64/lam-u57.rd: Likewise. * testsuite/ld-x86-64/pr32191-x32.d: New file. * testsuite/ld-x86-64/pr32191.d: Likewise. * testsuite/ld-x86-64/pr32191.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run PR ld/32191 tests. Signed-off-by: H.J. Lu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #8 from Dan McDonald --- Nope. -w was intentional. it's the v8dbg_SmiTag symbol that's getting set to 0 and getting ignored. The v8dbg_SmiTagMask is set to 0x1 and is not. Something changed between 2.40 and 2.41 as far as I can tell; perhaps you should inspect diffs between those two releases to see what happened. I save the entire output on the large .a files, and here's what I see on 2.40 and earlier... Disassembly of section .data.v8dbg_SmiTagMask: : 0: 01 00 add%eax,(%eax) 2: 00 00 add%al,(%eax) Disassembly of section .bss.v8dbg_SmiTag: : 0: 00 00 add%al,(%eax) 2: 00 00 add%al,(%eax) Disassembly of section .data.v8dbg_HeapObjectTagMask: : 0: 03 00 add(%eax),%eax 2: 00 00 add%al,(%eax) And here's what I see on 2.41 and later... Disassembly of section .data.v8dbg_SmiTagMask: : 0: 01 00 add%eax,(%eax) 2: 00 00 add%al,(%eax) Disassembly of section .data.v8dbg_HeapObjectTagMask: : 0: 03 00 add(%eax),%eax 2: 00 00 add%al,(%eax) v8dbg_SmiTagMask is getting dropped, and so are all other values set to 0. -- You are receiving this mail because: You are on the CC list for the bug.
Re: as aborts after buffer overflow
Hello Nick, I found the e-mail address on an old binutils doc page, and unfortunately I didn't realize how old it was. But true, the current doc page address is present in the rpm info, next time I will register. I wanted to know how exactly gcc translates such expressions like n * 0x1001. People are talking about multiplication being not slower than any other arithmetic operation on modern processors, but in fact I got the code (n << 12) + n, no matter which form I used in the C source. OK, it was with -O0, but it would be quite illogical to translate multiplication to shift on -O0, and to multiplication on -O3. Not frequently, but similar question occur from time to time. The default assembly listing page width is too narrow, I don't like reading folded source lines, truncated lines are even worse (or better?). Even 132 characters are not enough, but rhs-width wouldn't work with whatever sensible width. I am attaching the asm source. I applied the same command line, except -c replaced by -S. br PK On Thu, 2024-09-26 at 16:33 +0100, Nick Clifton wrote: > Hi Peter, > > > gcc -c -O1 -ggdb -masm=intel -Wa,-acdhlgn=gfp_library.lst -Wa,-- > > listing-lhs-width=4,--listing-rhs-width=132 -o gfp_library.o > > gfp_library.c > > In the future if you have other bugs like this to report, please > could you capture the compiler's assembler output and provide that > as the test file, rather than the C source ? The reason being that > this eliminates one step in the process and it means that I do not > need to have exactly the same version of gcc installed on my machine. > > Also - it really helps if you can file a bug report with the binutils > bugzilla system: > https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils > > This lets us track the bug and any discussion about it. Plus we can > put comments in the code referring to the bug's PR number and even > create > new tests that refer back to the bug report as well. > > As it happens however I am able to reproduce the problem locally, > and the first thing that occurs to be is to wonder why you are > capturing an assembler listing ? And given that it is needed, why > do you need a limit on the width of the source code in the listing ? > > The problem is obviously in the listing code, which is old and > crufty. > I am taking a look however and I may be able to find a solution. > > Cheers > Nick > .file "gfp_library.c" .intel_syntax noprefix .text .Ltext0: .file 0 "/home/peter/tmp" "gfp_library.c" .section.rodata.str1.1,"aMS",@progbits,1 .LC0: .string "/usr/lib64/libc.so.6" .LC1: .string "realloc" .text .globl gfp_lib_init .type gfp_lib_init, @function gfp_lib_init: .LFB1: .file 1 "gfp_library.c" .loc 1 20 1 view -0 .cfi_startproc sub rsp, 8 .cfi_def_cfa_offset 16 .loc 1 21 3 view .LVU1 .loc 1 21 18 is_stmt 0 view .LVU2 mov esi, 1 mov edi, OFFSET FLAT:.LC0 calldlopen .LVL0: mov rdi, rax .loc 1 21 16 discriminator 1 view .LVU3 mov QWORD PTR libc_so[rip], rax .loc 1 23 12 view .LVU4 mov eax, 1 .loc 1 21 6 discriminator 1 view .LVU5 testrdi, rdi je .L1 .LBB4: .LBI4: .loc 1 13 20 is_stmt 1 view .LVU6 .LBB5: .loc 1 15 3 view .LVU7 .loc 1 15 24 is_stmt 0 view .LVU8 mov esi, OFFSET FLAT:.LC1 calldlsym .LVL1: .LBE5: .LBE4: .loc 1 21 48 discriminator 1 view .LVU9 testrax, rax seteal movzx eax, al .L1: .loc 1 26 1 view .LVU10 add rsp, 8 .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE1: .size gfp_lib_init, .-gfp_lib_init .local libc_so .comm libc_so,8,8 .Letext0: .file 2 "/usr/lib/gcc/x86_64-redhat-linux/14/include/stddef.h" .file 3 "/usr/include/dlfcn.h" .section.debug_info,"",@progbits .Ldebug_info0: .long 0x16c .value 0x5 .byte 0x1 .byte 0x8 .long .Ldebug_abbrev0 .uleb128 0x9 .long .LASF8 .byte 0x1d .long .LASF0 .long .LASF1 .quad .Ltext0 .quad .Letext0-.Ltext0 .long .Ldebug_line0 .uleb128 0x3 .long .LASF2 .byte 0x2 .byte 0xd6 .byte 0x17 .long 0x3a .uleb128 0x4 .byte 0x8 .byte 0x7 .long .LASF4 .uleb128 0x3 .long .LASF3 .byte 0x1 .byte 0x7 .byte 0xf .long 0x4d .uleb128 0xa .long 0x61 .long 0x61 .uleb128 0x1 .long 0x61 .uleb128 0x1 .long 0x2e .byte 0 .uleb128 0xb .byte 0x8 .uleb128 0x5 .long 0x61
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #15 from Dan McDonald --- 1.) Thank you for confirming there was a doc update and I should've RTFM more carefully. There's a philosophical argument about surprising chnages, but given the next item I'm not going to raise a stink. 2.) My use of the `-fno-zero-initialized-in-bss` compiler/gcc flag cured what ailed me. This was educational. Thank you for your time & patience. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211
--- Comment #14 from Nick Clifton ---
(In reply to Dan McDonald from comment #13)
> Did this change in 2.41 include updates in the man page or other user
> documentation? If so, sorry for missing it.
Yes. It includes this change to the binutils/doc/binutils.texi file
which gets translated into man pages as well as an info file:
@item -D
@itemx --disassemble-all
-Like @option{-d}, but disassemble the contents of all sections, not just
-those expected to contain instructions.
+Like @option{-d}, but disassemble the contents of all non-empty
+non-bss sections, not just those expected to contain instructions.
+@option{-j} may be used to select specific sections.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gprofng/32207] [collect app] Error in parsing the -O option
https://sourceware.org/bugzilla/show_bug.cgi?id=32207 --- Comment #1 from Sourceware Commits --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=519aef2dae56a3b71016ed3a39929f59e3a0955a commit 519aef2dae56a3b71016ed3a39929f59e3a0955a Author: Vladimir Mezentsev Date: Wed Sep 25 15:31:34 2024 -0700 Fix 32207 [gprofng collect app] Error in parsing the -O option gprofng/ChangeLog 2024-09-25 Vladimir Mezentsev PR 32207 * src/collctrl.cc (preprocess_names): Fix the size in strndup. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32219] New: ELF orphan placement doesn't work well without .interp
https://sourceware.org/bugzilla/show_bug.cgi?id=32219 Bug ID: 32219 Summary: ELF orphan placement doesn't work well without .interp Product: binutils Version: 2.44 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- ldelf_place_orphan uses .interp as placement anchor. For ELF targets without .interp in linker script, like hppa64-hp-hpux11.23 and nds32le-linux-gnu, it doesn't place orphaned note sections very well, which leads to hppa64-hp-hpux11.23 +FAIL: ld-elf/pr23658-1e nds32le-linux-gnu +FAIL: ld-elf/pr23658-1e -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/32207] [collect app] Error in parsing the -O option
https://sourceware.org/bugzilla/show_bug.cgi?id=32207 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Vladimir Mezentsev --- Update status as resolved/fixed. -- You are receiving this mail because: You are on the CC list for the bug.
