[Bug binutils/27264] stack overflow in cxxfilt, demangle_type, rust-demangle.c:854

2021-12-21 Thread 2243829852 at qq dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27264

whl <2243829852 at qq dot com> changed:

   What|Removed |Added

 CC||2243829852 at qq dot com

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


[Bug ld/28709] [RISC-V] a unused section can't be removed with -gc-sections

2021-12-21 Thread lifang_xia at linux dot alibaba.com
https://sourceware.org/bugzilla/show_bug.cgi?id=28709

--- Comment #3 from lifang_xia at linux dot alibaba.com ---
The gas of riscv will split frag in md_assemble if the insn could be relaxed in
linker.tc-riscv.c:1372 (append_insn)

/* We need to start a new frag after any instruction that can be
   optimized away or compressed by the linker during relaxation, to prevent
   the assembler from computing static offsets across such an instruction.
   This is necessary to get correct EH info.  */
if (reloc_type == BFD_RELOC_RISCV_CALL
|| reloc_type == BFD_RELOC_RISCV_CALL_PLT
|| reloc_type == BFD_RELOC_RISCV_HI20
|| reloc_type == BFD_RELOC_RISCV_PCREL_HI20
|| reloc_type == BFD_RELOC_RISCV_TPREL_HI20
|| reloc_type == BFD_RELOC_RISCV_TPREL_ADD)
  {
frag_wane (frag_now);
frag_new (0);
  }
--
The cfi_add_advance_loc will record the last symbol and current symbol, both of
the symbols are temp symbol which named .L0. And both of them are in the
section .test11 which should be removed in linker. I name then to and from.

Because of the frag are splited, the to and from not the same frag.

Therefore, the gas will create a rs_cfa frag in .eh_frame for
DW_CFA_advance_loc while dw2cfi.c(output_cfi_insn). The symbol to(.L0) and
from(.L0) are in the section should be removed in linker.
--
static void
output_cfi_insn (struct cfi_insn_data *insn)
{
  offsetT offset;
  unsigned int regno;

  switch (insn->insn)
{
case DW_CFA_advance_loc:
  {
symbolS *from = insn->u.ll.lab1;
symbolS *to = insn->u.ll.lab2;

if (symbol_get_frag (to) == symbol_get_frag (from))
  {
...
  }
else
  {
expressionS exp;

exp.X_op = O_subtract;
exp.X_add_symbol = to;
exp.X_op_symbol = from;
exp.X_add_number = 0;

/* The code in ehopt.c expects that one byte of the encoding
   is already allocated to the frag.  This comes from the way
   that it scans the .eh_frame section looking first for the
   .byte DW_CFA_advance_loc4.  Call frag_grow with the sum of
   room needed by frag_more and frag_var to preallocate space
   ensuring that the DW_CFA_advance_loc4 is in the fixed part
   of the rs_cfa frag, so that the relax machinery can remove
   the advance_loc should it advance by zero.  */
frag_grow (5);
*frag_more (1) = DW_CFA_advance_loc4;

frag_var (rs_cfa, 4, 0, DWARF2_LINE_MIN_INSN_LENGTH << 3,
  make_expr_symbol (&exp), frag_now_fix () - 1,
  (char *) frag_now);
  }
  }
  break; 


The riscv backend will create a reloc named BFD_RELOC_RISCV_CFA in
riscv_pre_output_hook. The reloc  depends on the symbol to(.L0) and from(.L0).

And riscv backend will convert BFD_RELOC_RISCV_CFA  to R_RISCV_SET6 and
R_RISCV_SUB6 in md_apply_fix.

That's why .eh_frame depends on .text.test111

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


[Bug ld/28603] Incorrect branch offset from the start of a function after enable LTO

2021-12-21 Thread sen2403 at hotmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28603

--- Comment #4 from Eason Lai  ---
(In reply to Nick Clifton from comment #3)
> (In reply to Eason Lai from comment #1)
> > I have tried to reproduce the issue by creating a simple code for reference,
> > but no lucky. If anyone else could give me hint which part of linker may
> > causes this problem, I will try deep dive the source code and find I can
> > help or not. Thank you.
> 
> Is this ARM/AArch64 code that you are talking about ?
> 
> If so then the code you will want to look at is in the bfd/ directory,
> specifically the elf32-arm.c and/or elfxx-aarch64.c files.  Look for the
> functions which are used to resolve relocations.
> 
> It is strange that LTO is causing this problem.  I am not sure why this
> would cause the effect that you are seeing.  Is it possible that the bad
> code still has a relocation associated with it which would put the correct
> address into place when the program is loaded ?
> 
> Cheers
>   Nick

Thanks for reply.
I am using ARM CM4 and no relocation when the program is loaded. 

I have checked the elf32-arm.c, and it is a large file and not easy to figure
out the problem by non-professionals like me. If any professional can help on
this, I will really really appreciate it. Thank you very much.

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


[Bug ld/28682] GCC can no longer catch EH on windows

2021-12-21 Thread euloanty at live dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28682

--- Comment #1 from cqwrteur  ---
i tried 2.37 and it works. Just recent patches break windows completely. Please
i need a fix

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