public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* .cfi_startproc/.cfi_endproc associated with an empty function
@ 2023-03-24  4:04 Fangrui Song
  2023-03-24  7:14 ` Jan Beulich
  0 siblings, 1 reply; 2+ messages in thread
From: Fangrui Song @ 2023-03-24  4:04 UTC (permalink / raw)
  To: binutils, Andrew Pinski

Hello, https://github.com/llvm/llvm-project/issues/61434 reported an
issue that Call Frame Information FDE associated with an empty PC
range (address_range == 0) can cause trouble with .eh_frame linking.
For your convenience, you may copy and paste the commands on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109267 .
I think the problem can be addressed with one of the following methods:

* GCC and Clang can avoid generating `.cfi_startproc/.cfi_endproc` for
empty functions (literally no instruction (no RET or NOP or TRAP),
st_size is zero)
* GNU assembler and LLVM integrated assembler can avoid generating FDE
for `.cfi_startproc/.cfi_endproc` associated with empty functions.
* Linkers can discard FDE associated with empty functions. I think GNU
ld seems to do this, but I am unsure whether it's enforced. Even if I
know that --icf=all and --gc-sections have some effects on .eh_frame
linking, without using the two features discarding input sections
magically appears to deviate from the ELF spirit.
* libgcc_s/libunwind ignore FDE associated with empty functions.

What are your thoughts?

Ignoring `.cfi_startproc/.cfi_endproc` associated with empty functions
has the advantage of decreasing relocatable object file sizes.
I have played with the LLVM integrated assembler a bit and find it
straightforward to patch non-RISC-V ports.
For RISC-V, due to the currently not-so-robust linker relaxation
implementation in LLVM MC, it will take more effort.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: .cfi_startproc/.cfi_endproc associated with an empty function
  2023-03-24  4:04 .cfi_startproc/.cfi_endproc associated with an empty function Fangrui Song
@ 2023-03-24  7:14 ` Jan Beulich
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Beulich @ 2023-03-24  7:14 UTC (permalink / raw)
  To: Fangrui Song; +Cc: binutils, Andrew Pinski

On 24.03.2023 05:04, Fangrui Song wrote:
> Hello, https://github.com/llvm/llvm-project/issues/61434 reported an
> issue that Call Frame Information FDE associated with an empty PC
> range (address_range == 0) can cause trouble with .eh_frame linking.
> For your convenience, you may copy and paste the commands on
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109267 .
> I think the problem can be addressed with one of the following methods:
> 
> * GCC and Clang can avoid generating `.cfi_startproc/.cfi_endproc` for
> empty functions (literally no instruction (no RET or NOP or TRAP),
> st_size is zero)
> * GNU assembler and LLVM integrated assembler can avoid generating FDE
> for `.cfi_startproc/.cfi_endproc` associated with empty functions.
> * Linkers can discard FDE associated with empty functions. I think GNU
> ld seems to do this, but I am unsure whether it's enforced. Even if I
> know that --icf=all and --gc-sections have some effects on .eh_frame
> linking, without using the two features discarding input sections
> magically appears to deviate from the ELF spirit.
> * libgcc_s/libunwind ignore FDE associated with empty functions.
> 
> What are your thoughts?

I don't think assemblers should ignore directives. But compilers may
elect to avoid emitting them.

Jan

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-03-24  7:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-24  4:04 .cfi_startproc/.cfi_endproc associated with an empty function Fangrui Song
2023-03-24  7:14 ` Jan Beulich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).