[Bug gold/23245] New: memory leak with static link stdc++ with --no-gnu-unique at dlclose
https://sourceware.org/bugzilla/show_bug.cgi?id=23245 Bug ID: 23245 Summary: memory leak with static link stdc++ with --no-gnu-unique at dlclose Product: binutils Version: 2.25 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: bknt814 at gmail dot com CC: ian at airs dot com Target Milestone: --- I static link stdc++ gcc into a dso with --no-gnu-unique to independence c++ on old system and let the dso can be dynamic unloaded from memory so use glod and option --no-gnu-unique. It works but a huge of memory leak if call dlopen/dlclose a long time. for more info please look at below: https://stackoverflow.com/questions/49992058/dlclose-cant-work-if-make-a-empty-dso-with-link-static-libstdc https://stackoverflow.com/questions/50402314/static-link-stdc-without-stb-gnu-unique-cause-memory-leak-when-dlclose I hope it is not a bug. But how can I fix the memory leak? -- 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/23242] aarch64: objdump should treat SBO bits consistent
https://sourceware.org/bugzilla/show_bug.cgi?id=23242 Raimar Falke changed: What|Removed |Added Summary|aarch64: objdump requires |aarch64: objdump should |ignores bits to be set in |treat SBO bits consistent |ldar| -- 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/23242] aarch64: objdump should treat SBO bits consistent
https://sourceware.org/bugzilla/show_bug.cgi?id=23242 Raimar Falke changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Raimar Falke --- Changing the summary and set the issue to unconfirmed. -- 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/23230] aarch64: objdump disassembles invalid mrs
https://sourceware.org/bugzilla/show_bug.cgi?id=23230 --- Comment #3 from Egeyar Bagcioglu --- I prepared a patch according to "ARM Architecture Reference Manual, ARMv8, for ARMv8-A architecture profile". However, the patch triggered a failure in a test-case. Then, I realized that what my patch does was reverting the following patch: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=df7b4545b2b49572ab63690c130df973af109615 It seems that the definitions of mrs and msr were relaxed on purpose. I have also checked his old e-mail about it: https://sourceware.org/ml/binutils/2014-09/msg00022.html I see what it does. It enables one to define instructions such as sys, sysl, hint and clrex in terms of mrs and msr. However, it is not mentioned in the manual. Moreover, as pointed out by this bug, that patch lets a big range of undefined instructions to fall into msr/mrs definition. Because, the above 4 instructions each have many more defined bits than mrs/msr do. My instinct to follow the manual would prefer the previous stricter version of mrs/msr. I am not able to add Jiong, the patch owner, to the CC list of this bug. I'm notifying him via e-mail to get his opinion on this matter. I hope he can tell us why the above patch was necessary so that a better informed decision can be made on the matter. -- 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
Re: [Bug binutils/23230] aarch64: objdump disassembles invalid mrs
Hi Jiong, I am looking at the following bug and it concerns one of your old patches. I could not add you to the CC list of the bug. Therefore, I'm notifying you by forwarding my update on the bug. Regards, Egeyar On 05/29/2018 08:47 PM, egeyar.bagcioglu at oracle dot com wrote: https://sourceware.org/bugzilla/show_bug.cgi?id=23230 --- Comment #3 from Egeyar Bagcioglu --- I prepared a patch according to "ARM Architecture Reference Manual, ARMv8, for ARMv8-A architecture profile". However, the patch triggered a failure in a test-case. Then, I realized that what my patch does was reverting the following patch: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=df7b4545b2b49572ab63690c130df973af109615 It seems that the definitions of mrs and msr were relaxed on purpose. I have also checked his old e-mail about it: https://sourceware.org/ml/binutils/2014-09/msg00022.html I see what it does. It enables one to define instructions such as sys, sysl, hint and clrex in terms of mrs and msr. However, it is not mentioned in the manual. Moreover, as pointed out by this bug, that patch lets a big range of undefined instructions to fall into msr/mrs definition. Because, the above 4 instructions each have many more defined bits than mrs/msr do. My instinct to follow the manual would prefer the previous stricter version of mrs/msr. I am not able to add Jiong, the patch owner, to the CC list of this bug. I'm notifying him via e-mail to get his opinion on this matter. I hope he can tell us why the above patch was necessary so that a better informed decision can be made on the matter. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20319] as and objdump allow "fmov sn, xm"
https://sourceware.org/bugzilla/show_bug.cgi?id=20319 Raimar Falke changed: What|Removed |Added CC||i-bugzilla-sourceware-org-k ||asujfzh at rf dot risimo.net --- Comment #3 from Raimar Falke --- The issue is still present in 2.30. Sample input: $ cat fmov.asm .global main .section .text .balign 4 main: fmov d4, w2 fmov s4, x2 fmov w4, d2 fmov x4, s2 ret $ The assembler should mark these instructions as invalid. -- 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 ld/23161] __bss_start, _end and _edata aren't marked as hidden
https://sourceware.org/bugzilla/show_bug.cgi?id=23161 Mark Johnston changed: What|Removed |Added CC||markj at FreeBSD dot org --- Comment #2 from Mark Johnston --- (In reply to Alan Modra from comment #1) FreeBSD's libc uses _end to initialize curbrk. At a glance, OpenBSD and NetBSD appear to do this as well. For this use case it is crucial that _end be present in the executable's dynsym, since libc will otherwise use its internal definition. I peeked at the glibc sources; it seems that they rely on Linux's brk() system call returning the current break value when given an input of 0. This is used to lazily initialize the curbrk. We could probably add a similar hack to FreeBSD to get around this, but as noted, we're not the only ones relying on this behaviour. -- 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 ld/23161] __bss_start, _end and _edata aren't marked as hidden
https://sourceware.org/bugzilla/show_bug.cgi?id=23161 --- Comment #3 from H.J. Lu --- Should we not define __bss_start/_end/_edata in shared libraries at all and always use the definitions in executable? Will this work for FreeBSD? -- 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 ld/23244] RISC-V 64 relocation truncated to fit in case of undefined weak references
https://sourceware.org/bugzilla/show_bug.cgi?id=23244 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-30 CC||wilson at gcc dot gnu.org Assignee|unassigned at sourceware dot org |wilson at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jim Wilson --- I see the problem. This is working for 32-bit targets, and failing for 64-bit targets. For a 32-bit target, the offset ends up as 0x7000 which when added to 0x9000 via auipc gives zero. But for a 64-bit target, the addition gives 0x1 which is not the right address. We can only address +/- 0x8000 from the current PC, which means address zero is not in range. The other part of this problem is that relaxation is deliberately disabled for weak functions, as the address might change later when another object file or library is added in. I think the only easy workaround at the moment would be to use riscv32 instead of riscv64. I think we would need a new code model to make this work for riscv64. Or alternatively compile with -fpie, which then indirects via the GOT which will be in range, but requires dynamic linker support. There might be a more complex way to fix this by changing how the R_RISCV_CALL relocation works, so that it writes both instruction opcodes and fields, in which case we can handle a zero address directly, or alternatively we can relax it multiple times. I'm not sure if this can work, and may not have time to try it for a while. -- 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 ld/23161] __bss_start, _end and _edata aren't marked as hidden
https://sourceware.org/bugzilla/show_bug.cgi?id=23161 --- Comment #4 from Mark Johnston --- (In reply to H.J. Lu from comment #3) I suspect that would address the problem I brought up here: https://sourceware.org/ml/binutils/2018-05/msg00300.html I'm happy to test patches. If I can apply the change to the binutils 2.17.50 sources in FreeBSD's base system, we can test a build of the entire ports tree (~20,000 third-party packages). -- 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 ld/23244] RISC-V 64 relocation truncated to fit in case of undefined weak references
https://sourceware.org/bugzilla/show_bug.cgi?id=23244
--- Comment #2 from Sebastian Huber ---
Thanks for your analysis.
Calling a weakly undefined function is undefined behaviour. Would it be
possible to replace the call to zero with a call to the current PC (infinite
loop) or a nop?
On the ARM architecture it looks like a nop is created:
.type _start, %function
_start:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, lr}
movwr3, #:lower16:f
movtr3, #:upper16:f
cbz r3, .L1
bl f
bl f
.L1:
pop {r3, pc}
.size _start, .-_start
.weak f
Final executable code (Thumb-2):
Disassembly of section .text:
9000 <_start>:
9000: b508push{r3, lr}
9002: f240 0300 movwr3, #0
9006: f2c0 0300 movtr3, #0
900a: b11bcbz r3, 9014 <_start+0x14>
900c: f3af 8000 nop.w
9010: f3af 8000 nop.w
9014: bd08pop {r3, pc}
9016: bf00nop
--
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
