[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29183: 27.0.50; SIGSEGV on C-g on Windows
From: |
John Mastro |
Subject: |
bug#29183: 27.0.50; SIGSEGV on C-g on Windows |
Date: |
Wed, 8 Nov 2017 15:41:05 -0800 |
Paul Eggert <eggert@cs.ucla.edu> wrote:
> What is the difference in assembly-language output when you compile with
> this:
>
> static struct thread_state GCALIGNED main_thread;
>
> versus this?
>
> static struct thread_state main_thread;
I don't know/read assembly, so I'm not sure if this is what you're
looking for, but the only line in the diff between the two resulting
files that mentions main_thread is that the output from the source with
GCALIGNED says:
.lcomm main_thread,592,8
Whereas the assembly output from the source without GCALIGNED says:
.lcomm main_thread,592,32
The diff is quite large though, 3,685 lines. Almost all of them are
either ".uleb128" or ".long" followed by an operand (the operand being
what differs).
> What is the assembly-language output when compiling the following little
> program, when compiled the same way that you compile thread.c?
>
> struct thread_state { int x; };
> static struct thread_state __attribute__ ((aligned (8))) a;
> static struct thread_state b;
> struct thread_state *c[] = { &a, &b };
>
> On my platform, compiling this with gcc -S yields the following, which looks
> properly aligned:
>
> .file "t.c"
> .local a
> .comm a,4,8
> .local b
> .comm b,4,4
> .globl c
> .data
> .align 16
> .type c, @object
> .size c, 16
> c:
> .quad a
> .quad b
> .ident "GCC: (GNU) 7.2.1 20170915 (Red Hat 7.2.1-2)"
> .section .note.GNU-stack,"",@progbits
I get the following:
.file "t.c"
.text
.Ltext0:
.cfi_sections .debug_frame
.globl c
.data
.align 16
c:
.quad a
.quad b
.lcomm b,4,4
.lcomm a,4,8
.text
.Letext0:
.file 1 "t.c"
.section .debug_info,"dr"
[... a bunch of .Ldebug_* sections ...]
.Ldebug_line0:
.section .debug_str,"dr"
.ident "GCC: (Rev1, Built by MSYS2 project) 7.2.0"
Let me know if I can provide any other information.
John
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, John Mastro, 2017/11/06
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, Eli Zaretskii, 2017/11/06
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, John Mastro, 2017/11/07
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, Eli Zaretskii, 2017/11/07
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, John Mastro, 2017/11/07
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, Eli Zaretskii, 2017/11/07
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, John Mastro, 2017/11/08
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, Eli Zaretskii, 2017/11/08
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, Paul Eggert, 2017/11/08
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows,
John Mastro <=
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, Paul Eggert, 2017/11/08
- bug#29183: 27.0.50; SIGSEGV on C-g on Windows, John Mastro, 2017/11/09
bug#29183: 27.0.50; SIGSEGV on C-g on Windows, Davor Rotim, 2017/11/09