[Bug ld/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 --- Comment #5 from ma.jiang at zte dot com.cn --- Hi guys, I encoutered this bug when trying to compile a static-linked perf. In my option, there were two serious problem here. First of all, ld should never create a broken executable silently. If "-static" is conflicted with any other option, ld should abort and print information about the conflict. Secondly, "--dynamic-list" should be documented more clearly and directly. "Specify the name of a dynamic list file to the linker. This is typically used when creating shared libraries to specify a list of global symbols whose references shouldn't be bound to the definition within the shared library, or creating dynamically linked executables to specify a list of symbols which should be added to the symbol table in the executable." This paragraph（listed above） in man pages is too obscure to tell users what the option really mean. I thinks we should clearly describe what the option do(and some symbol into dynamic symbol table?) first, and then tell users what are the typical scenarios. -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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/21086] static linking with --dynamic-list adds dynamic section and interpreter
https://sourceware.org/bugzilla/show_bug.cgi?id=21086 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn -- 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 gas/20934] New: wrong replacements for ld/sd on mips-o32 abi
https://sourceware.org/bugzilla/show_bug.cgi?id=20934 Bug ID: 20934 Summary: wrong replacements for ld/sd on mips-o32 abi Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ma.jiang at zte dot com.cn Target Milestone: --- Hi all, When using mips-o32 abi, gas will replace ld/sd into lw/sw. This behavior seems strange. The gas could produce wrong codes easily without any warnings. Using "gas -mabi=32", a "ld $v0, ($a1)" will be silently translated into "lw v0,0(a1);lw v1,4(a1)". IMO, this is NOT right, because the v1 register is changed and the coder probably could not notice this. -- 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/16720] wrong overflow check in R_MIPS_HI16
https://sourceware.org/bugzilla/show_bug.cgi?id=16720 ma.jiang at zte dot com.cn changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #5) > Hi Ma, > > Sorry for the delay in reviewing this PR. > > I agree with your analysis, so I have gone ahead and checked in your > suggested patch. Thanks very much for creating it! > > Cheers > Nick Hi Nick， It's happy to see this local patch go upstream. Thanks, I'll close the bug now. -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #27 from ma.jiang at zte dot com.cn --- (In reply to ma.jiang from comment #26) > (In reply to cvs-com...@gcc.gnu.org from comment #24) > Hi Nick, > Could you please say more about the this? What problems do you encountered > with sorted segments? I really can not understand why non-ordered segments > are needed... Sorry, Just found the dicussion in "https://sourceware.org/ml/binutils/2016-11/msg00338.html";. Are we dealing with the dilemma that user provided a PHDR which is not consistent with the elf spec? I agree that if user has provided PHDRs, we should not do the sorting. Users should have the right to place their segments when they provided the PHDRs themselves. We could just give a warning if user provided PHDRs violated the elf spec. -- 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/20823] invalid "tail +16c" still used
https://sourceware.org/bugzilla/show_bug.cgi?id=20823 --- Comment #7 from ma.jiang at zte dot com.cn --- (In reply to Alan Modra from comment #6) > Yes of course. By the "gas patch", I meant the patch to gas/ that made the > gas Makefile use the acx.m4 machinery. We still have acx.m4 to fix, which > we'll import from gcc when/if that patch goes in. Note that I don't have > any authority to approve the gcc patch, and the gcc folk may well reject it > on the grounds that people with gnu tools won't be using tail anyway, so it > may be better to keep using the ancient form of tail. Hi Alan, Thanks for the reply. I'll keep sending the gcc patch for some time, although I guess you are right... It seems that the gcc guys do not care this tiny problem. -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #26 from ma.jiang at zte dot com.cn --- (In reply to cvs-com...@gcc.gnu.org from comment #24) > The master branch has been updated by Nick Clifton : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=cd58485720b47d80fed0b281d15a9198f43eaf0c > > commit cd58485720b47d80fed0b281d15a9198f43eaf0c > Author: Nick Clifton > Date: Mon Nov 28 17:45:22 2016 + > > Partially revert patch for PR 20815 - do not sort the PT_LOAD segments. > Non-ordered segments are needed by the Linux kernel. > > PR ld/20815 > * elf.c (phdr_sorter): Delete. > (assign_file_positions_except_relocs): Do not sort program > headers. Hi Nick, Could you please say more about the this? What problems do you encountered with sorted segments? I really can not understand why non-ordered segments are needed... -- 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/16720] wrong overflow check in R_MIPS_HI16
https://sourceware.org/bugzilla/show_bug.cgi?id=16720 --- Comment #3 from ma.jiang at zte dot com.cn --- Hi all, This bug still exist in the trunk code. Using the attached files, I can still get the error "relocation truncated to fit: R_MIPS_HI16 against `_gp_disp'". This is *NOT* right, as the mips abi said that R_MIPS_HI16 need no overflow checks. Moreover, Only the o32 abi support R_MIPS_HI16 for _gp_disp, per the mips abi. R_MIPS_HI16 should never get overflowed, because under o32 abi, the address width is 32. So, I think we should just get rid of the overflow check for R_MIPS_HI16. Here is the patch for trunk. --- bfd/elfxx-mips.c.orig 2016-11-28 23:09:23.343671301 +0800 +++ bfd/elfxx-mips.c2016-11-28 23:23:49.452670956 +0800 @@ -5875,7 +5875,6 @@ mips_elf_calculate_relocation (bfd *abfd value = mips_elf_high (addend + gp - p - 1); else value = mips_elf_high (addend + gp - p); - overflowed_p = mips_elf_overflow_p (value, 16); } break; -- 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/20823] invalid "tail +16c" still used
https://sourceware.org/bugzilla/show_bug.cgi?id=20823 ma.jiang at zte dot com.cn changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from ma.jiang at zte dot com.cn --- (In reply to Alan Modra from comment #3) > I applied the gas patch a week ago. git commit 2d7f2507d. One more thing, How about the acx.m4 in gcc project? There are still "tail +16c" in that file. -- 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/20823] invalid "tail +16c" still used
https://sourceware.org/bugzilla/show_bug.cgi?id=20823 ma.jiang at zte dot com.cn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from ma.jiang at zte dot com.cn --- (In reply to Alan Modra from comment #3) > I applied the gas patch a week ago. git commit 2d7f2507d. Hi Alan, Thanks. I have checked both binutils and gcc sources. Now that you have fix the problem, I will close the bug now. And by the way, please give me a note if you have get things done next time... I am sending mails time and time again to gcc-patc...@gcc.gnu.org, like a fool... -- 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/20823] invalid "tail +16c" still used
https://sourceware.org/bugzilla/show_bug.cgi?id=20823 --- Comment #2 from ma.jiang at zte dot com.cn --- Hi Alan, I have added you to the CC list, as you replied my mail. Sorry, if it makes troubles. I have send some mails to gcc-patc...@gcc.gnu.org as you suggested, but it seems that no one care... On the other side, I know that after your fix , gas could use the right command "cmp --ignore-initial" on most modern systems. Should we apply your patch first? -- 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/20823] invalid "tail +16c" still used
https://sourceware.org/bugzilla/show_bug.cgi?id=20823 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||amodra at gmail dot com -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 ma.jiang at zte dot com.cn changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #22 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #20) > Hi Ma, > > Well this has turned out to be a humongous patch. The problem is that > some targets break the ELF rules, so I needed to add special cases for them. > Plus the linker was not detecting all the cases where invalid program > headers were being created. Plus there were lots of test cases in the > linker testsuite that needed fixing. *sigh* Still I have finally finished > the patch and applied it. Please try out the latest development sources and > let me know if you are happy. (You could also close this PR if you are > happy...) > > Cheers > Nick Hi Nick, Thanks. I have checked the committed patch(havn't try the code though), and believe that my problem has get fixed. But I am not very happy ,as you guys have done all the work leaving me no change to "contribute to the community" :) -- 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/20852] glibc/MIPS strfry call strlen by bal not jalr
https://sourceware.org/bugzilla/show_bug.cgi?id=20852 --- Comment #4 from ma.jiang at zte dot com.cn --- Hi all, I have checked the source code of strfry.c ,and the build process. I believe that the generated binary is OK. In the strfry.s (add -save-temps ,and recompile strfry.c to get it), we get the following chunk. .loc 1 38 0 ld $25,%got_disp(__GI_strlen)($28) .reloc 1f,R_MIPS_JALR,__GI_strlen 1: jalr$25 It is clear that strfry.c call the hidden symbol __GI_strlen instead of normal strlen. So the optimized binary is OK. GLIBC has made some small tricks in include/string.h which change many global symbols to internal hidden ones. At last, I think the superfluous load should really be eliminated. I know this might not be that easy as it looks.But with a little help of compiler(build a connection between the ld insn and corresponding jalr), I believe we could make it. -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #18 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #17) Hi Nick, I have tested the proposed patch. And yes, it does print error messages as expected, thanks! I only have two small question about the details. Firstly, the patch seem to agree with "the PHDR segment should be in the first load segment, if existed." in logic. But the comments and error messages are somewhat obscure. Secondly, the final error reason "File format not recognized" looks strange. should we add a "bfd_set_error (bfd_error_bad_value)"? -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #14 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #13) Hi Nick, now that the generated elf have a PT_PHDR segment, it must load the program header into memory, as the elf standard said clearly "Moreover, it may occur *ONLY IF* the program header table is part of the *MEMORY IMAGE* of the program". The program header table is not in any load segment of the invalid elf, so it is clear that the program header table is not part of the memory image of the elf file. I did not understand all the pricinples behind the elf standard.But,it seems to me "the existence of PT_PHDR is to tell others that you can find the program header table in the memory at the VMA specified by the PHDR segment". If it's not the case, I can not understand why we need a PT_PHDR segment. Anyway, the program header table can be read out from the elf file directly(with the guide of e_phoff). > OK - well if we can will. Provided that we do not break anything else of > course. Thanks,I believe we can make it. -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #12 from ma.jiang at zte dot com.cn --- Created attachment 9643 --> https://sourceware.org/bugzilla/attachment.cgi?id=9643&action=edit the invalid elf (In reply to Nick Clifton from comment #11) Hi Nick, I have checked your file. Yes, your elf is OK(as it does not have a PT_PHDR). I have found the way to create your elf on my server(gcc test.c -c; ld test.o pad.ld -o test). I create my elf using "gcc test.c pad.ld -o test".My elf do have a PT_PHDR. I have uploaded it,please check. > > > To tell the truth, it's not hard for me to find what is wrong(LOL). But > > I'm a tool-chain maintainer in my company, and there are a lot of normal > > users who will get totally confused by such problems. > > But hang on - why would a normal user be creating and using their own linker > scripts ? This is something that should be completely hidden from the user, > and something that they never have to worry about (or even know about). Trust me, there were so many such guys.This problem was reported by a expert in kernel(not in tool-chain...), when porting some hugepage tests to mips. Let us give them a hand, :) -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #9 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #8) Hi Nick, Thank you for the explanation.It cost you much time I guess :). It seems that whether the elf is valid become the most important divergence. I still insist it's not valid. > Now an ELF executable *may* elect to > make the program header be part of one of these program segments, in which > case that segment gets the PT_PHDR type and it should be mapped into memory > when the executable is loaded. But - the ELF standard does not require that > the program headers be contained in a program segment. Yes, the elf standard does not require " the program headers be contained in a program segment". But, now that the generated elf have a PT_PHDR segment, it must load the program header into memory, as the elf standard said clearly "Moreover, it may occur *ONLY IF* the program header table is part of the memory image of the program". The PT_PHDR existed, but the program header table is not loaded into memory, thus I insist the generated elf is not valid(if there were no such a PT_PHDR segment, the generated elf is ok). > Of course I realise that this does not help you with the case you > encountered - the linker silently producing a non-working binary. But at > issue here is that the linker script being used was broken, and if you are > using linker scripts then you really need to know what you are doing, and to > expect that you will have to do some deep debugging when things do not work > out as planned. I am sorry, but I really think that in this case the linker > cannot be expected to diagnose the problem for you. To tell the truth, it's not hard for me to find what is wrong(LOL). But I'm a tool-chain maintainer in my company, and there are a lot of normal users who will get totally confused by such problems. I hope the gnu-ld could give a warning at least, even if you do think the elf file is valid. Yes, the man who make mistake should pay the price, but they probably do not know what is wrong...Men are not saints.Let us make the linker more friendly for such guys. -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #6 from ma.jiang at zte dot com.cn --- Hi Nick, Thanks for the reply. This is a tricky problem. First of all , The elf specification does not say very clear about the first load segment. In my edition "Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2", there is such a sentence: "The first text page contains the ELF header, the program header table, and other information." (in the i386 sections ). So, I guess "the first load segment should contain program headers" is right at least for a i386-elf target? moreover,the elf specification said "If it is present,it must precede any loadable segment entry" about the PT_PHDR segment. Secondly, About the executable generated by the linker, I do NOT think it is a valid ELF format.The elf specification said "it may occur only if the program header table is part of the memory image of the program" about the PT_PHDR segment. Thank goodness，this time the specification said things clear. The generated executable has a PT_PHDR，but the segment is NOT a part of memory image of the program. lastly, about the patch. I feel sorry that it breaks many tests.Obviously, the patch need much more work. Maybe we should make it a warning instead of a fatal error? I am very glad to improve the patch, after we both agree with the final plan. There are some important divergences anyway (does the elf required the first load segment things? target specific or general?warnings or errors?). -- 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/20824] enable warn-shared-textrel by default
https://sourceware.org/bugzilla/show_bug.cgi?id=20824 --- Comment #2 from ma.jiang at zte dot com.cn --- (In reply to Mike Frysinger from comment #1) > patches should be sent to the binut...@sourceware.org mailing list for > discussion. there are problems with this particular patch, but that can be > ironed out after we discuss whether we want to do this in the first place. > > you'll also need to update gold. Thanks for the reply. I have send a mail to binut...@sourceware.org. for the things about gold: we did not use the gold linker,so I am not familiar with it. if this behavior change were accepted by the binutils community, I will pay some time for the gold. -- 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/20824] New: enable warn-shared-textrel by default
https://sourceware.org/bugzilla/show_bug.cgi?id=20824 Bug ID: 20824 Summary: enable warn-shared-textrel by default Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ma.jiang at zte dot com.cn Target Milestone: --- Created attachment 9636 --> https://sourceware.org/bugzilla/attachment.cgi?id=9636&action=edit enable warn-shared-textrel by default In gnu-ld, warn-shared-textrel is disabled by default. Why not to enable it by default? One of our customers found that he did not have enough memory to run his application after a recompilation. The root cause turn out to be a silly mistake that he forgot to add "-fPIC" for his shared libraries. Yes yes, the one who make mistakes got to pay the price, it's very reasonable. But there were no warning at all, a normal user(not a expert) probably did not know what was wrong (and how to fix). This does not seem reasonable... Although some arches(like x86-64) force all shared libraries to be PIC, there are some that does not. In my opinion, the linker should be a good place to make the warnings. So, warn-shared-textrel should be enable by default. attached patch enable "warn-shared-textrel" and add a new option to close this warning, is that ok? -- 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/20823] invalid "tail +16c" still used
https://sourceware.org/bugzilla/show_bug.cgi?id=20823 ma.jiang at zte dot com.cn changed: What|Removed |Added Attachment #9634|0 |1 is obsolete|| --- Comment #1 from ma.jiang at zte dot com.cn --- Created attachment 9635 --> https://sourceware.org/bugzilla/attachment.cgi?id=9635&action=edit change all "tail +16c" to "tail -c +16" sorry, please use this patch instead of the first one. -- 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/20823] New: invalid "tail +16c" still used
https://sourceware.org/bugzilla/show_bug.cgi?id=20823 Bug ID: 20823 Summary: invalid "tail +16c" still used Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ma.jiang at zte dot com.cn Target Milestone: --- Created attachment 9634 --> https://sourceware.org/bugzilla/attachment.cgi?id=9634&action=edit change all "tail +16c" to "tail -c +16" When porting patches from binutils2.24 to latest 2.27, I found some old mistakes still existed. "tail" now treat operands with leading '+' as file names, as POSIX has required since 2001. But there were still some uses of "tail +16c" in binutils. Attached patch change all "tail +16c" to valid "tail +c", is that ok? -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #4 from ma.jiang at zte dot com.cn --- Created attachment 9633 --> https://sourceware.org/bugzilla/attachment.cgi?id=9633&action=edit a dummy main.c to reproduce the bug -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #3 from ma.jiang at zte dot com.cn --- Created attachment 9632 --> https://sourceware.org/bugzilla/attachment.cgi?id=9632&action=edit linker script to reproduce the bug it seems that my zip can not be open by others(but ok by me...),so re-upload each files seperately. -- 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/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #2 from ma.jiang at zte dot com.cn --- Created attachment 9631 --> https://sourceware.org/bugzilla/attachment.cgi?id=9631&action=edit patch to fix the bug it seems that my zip can not open by others(but ok by me...),so re-upload each files seperately -- 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/20815] New: throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 Bug ID: 20815 Summary: throw errors for invalid load segment Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ma.jiang at zte dot com.cn Target Milestone: --- Created attachment 9628 --> https://sourceware.org/bugzilla/attachment.cgi?id=9628&action=edit files to reproduce the bug, and the fix. When doing some hugepage tests, I found gnu-ld would create a wrong elf when giving a wrong linker script. On a x86-64 machine, using attached demo could reproduce this bug ,just "gcc test.c pad.ld -o test". The generated "test" will receive a segv when staring(on a linux platform). The core problem is that ld create a segment for the faked section in "pad.ld", and this segment become the first load segment as the faked section has the lowest address. However, per the ELF specification, the first load segment should contain program headers. The linux kernel only try to find program headers in the first load segment as well. All together, when staring the generated "test", the kernel will put a wrong addr into AT_PHDR. Finally, the dynamic loader trigger the segv fault when accessing program headers at AT_PHDR. Of course, the root cause of this problem is "pad.ld" which breaks the ELF specification. But gnu-ld should stop creating output files and print warnings. Attached "segment-check.patch" adds a check in make_mapping(in elf.c) , it should be enough to fix the bug. -- 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/17550] Section groups (comdat/linkonce) create undefined symbols unnecessarily
https://sourceware.org/bugzilla/show_bug.cgi?id=17550 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||ma.jiang at zte dot com.cn --- Comment #1 from ma.jiang at zte dot com.cn --- I encountered this bug some days ago when using lto. The compiler build a lot of symbols like .LTHUNKxxx.xxx, some of them became undefined because of this bug. And finally, I could not get my executable(although everythis is ok in fact)... The _bfd_elf_section_already_linked should not drop alreay_linked sections simply.Relocating symbols to previous linked sections is also its responsiblity. -- 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/16720] wrong overflow check in R_MIPS_HI16
https://sourceware.org/bugzilla/show_bug.cgi?id=16720 ma.jiang at zte dot com.cn changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from ma.jiang at zte dot com.cn --- still no reply? I can not build my glibc(with -g3 option) due to this bug... -- 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/16787] LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787 --- Comment #12 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #10) > Sorry, but I still canont reproduce this failure. :-( > > H.J. - your test case does not demonstrated the problem, at least as far as > I can see. It shows the linker not referencing any source file when > complaining about the undefined reference: > > t13.o: In function `t3': > (.text+0x1a): undefined reference to `udf' > > Ma's bug report, if I understand it correctly, is about the linker > referencing the wrong source file (t4.c) in its output. Incidentally when I > run your test case on my system (x86_64 Fedora 20) I get the correct output: > > gcc -B./ -o x t13.o tt.o t2.o > t13.o: In function `t1': > /home/nickc/work/builds/gcc/current/x86_64-pc-linux-gnu/tests/t1.c:2: > warning: foobar > t13.o: In function `t3': > /home/nickc/work/builds/gcc/current/x86_64-pc-linux-gnu/tests/t3.c:2: > undefined reference to `udf' > > > Ma - your proposed patch might work - I have no way to test it at the moment > - but it does also have one flaw. It calls _bfd_dwarf2_cleanup_debug_info > without first checking to see if the input object file is an ELF format file. > > Ideally when we do have a fix for this problem we should add a test case to > the linker testsuite as well. Do you think that you could write one ? That > way, assuming that the test works for non-ARM based ELF targets I might be > able to reproduce the problem myself. > > Cheers > Nick Hi Nick, the testcase uploaded by H.J.Lu is a simpler version of mine.I use some macros to extend text seciont vma of t4.c, so that the wrong error shows the undefined referencing is in t4.c(In order to show how misleading the bug can be). H.J.Lu does not fake these macros, so the linker just can not find any file for the undefined referencing. Anyway ,the two tesecases are same in essence. I do not know why you can not reproduce the bug in your server.I have not use gold linker before.I think you could try H.J.Lu's advice. As to the fix, I think we could discuss it in detail after you reproduce the bug :-) -- 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/16787] LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787 --- Comment #9 from ma.jiang at zte dot com.cn --- Created attachment 7541 --> https://sourceware.org/bugzilla/attachment.cgi?id=7541&action=edit glibc libs -- 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/16787] LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787 --- Comment #8 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #6) > Hi Ma, > Please could you upload the libc.a and libg.a files that you are > using. I have tried to find some on the net, but so far I have failed. :-( > Cheers > Nick Hi Nick, I have uploaded the two libs. You could also use the testcase uploaded by H.J. Lu, which does not need a special libc. Sorry to waste so much time on these trivial things. I thought glibc was easy to get... -- 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/16787] LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787 --- Comment #5 from ma.jiang at zte dot com.cn --- Hi Nick, I'm using the 2.24 release.I tried to get the current mainline sources, but I found it was too hart to get them(when working in windows and behind a stupid firewall)... The toolchain you used have no definitions for "getgrgid", that is the reason why you do not get the same error as me.Could you find a glibc toolchain? As my first mail said, the warning for "getgrgid" is critical. I can reproduce this bug on gcc4.5.2+binutils2.21+glibc2.13 and gcc4.8.2+binutils2.24+glibc2.18. -- 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/16787] LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787
--- Comment #3 from ma.jiang at zte dot com.cn ---
(In reply to Nick Clifton from comment #1)
> Hi Ma,
>
> bug.sh tries to compile a file called tt.c which is missing from bin.zip.
> Could you upload that file please ?
>
> Cheers
> Nick
Hi Nick,
Thank you for your prompt reply. It's really nice to meet you, again. :-)
I have uploaded the missing tt.c, sorry for the mistake.In fact, tt.c is
just a main function which use a call to take t1234.o into the linking
process.
int main()
{
t2();
return 0;
}
--
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/16787] LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787 --- Comment #2 from ma.jiang at zte dot com.cn --- Created attachment 7523 --> https://sourceware.org/bugzilla/attachment.cgi?id=7523&action=edit missed file -- 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/16787] New: LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787
Bug ID: 16787
Summary: LD gives wrong error messages
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: ma.jiang at zte dot com.cn
Created attachment 7512
--> https://sourceware.org/bugzilla/attachment.cgi?id=7512&action=edit
for bug reproduce
unzip the attached file, put these files into the directory of a cross-compiler
for arm.Run the bug.sh. Linker will throw out error messages like :
t1234.o: In function `t1':
/home/majiang/toolchain_compile/ToolsChain/gcc4.5.2_glibc2.13.0/install/arm_eabi_gcc4.5.2_glibc2.13.0/bin/t1.c:2:
warning: Using 'getgrgid' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking
t1234.o: In function `tp_842':
/home/majiang/toolchain_compile/ToolsChain/gcc4.5.2_glibc2.13.0/install/arm_eabi_gcc4.5.2_glibc2.13.0/bin/t4.c:12:
undefined reference to `udf'
collect2: ld returned 1 exit status
But, in fact the reference to 'udf' is in t3.c as you can see from the source
codes.The Gnu Linker gives out a totally wrong message here.
==
This problem has something to do with the bfd interface
_bfd_dwarf2_slurp_debug_info.This function uses a cached debug info which is
wrong in some circumstance. More specifically, _bfd_dwarf2_slurp_debug_info
load and parse the debug info sections when ld generated getgrgid warning.At
that time,output sections(especially their vma) are not determined. When ld
generated the udf error, output sections have their vma now while
_bfd_dwarf2_slurp_debug_info still use the cached debug info. Finally,the bug
jump out. The find_line function add the section->output_section->vma to the
reloc offset of udf, and the aranges of compilation units in cached debug info
do not change with it. At last, the find_line function find a wrong file/lineno
for the udf reference.
=
To fix this problem, ld need to clear the wrong cache when things have changed.
My solution is to call the function below right after the lang_process function
call lang_size_sections (NULL, ! RELAXATION_ENABLED).
static void reset_all_debuginfo(void)
{
bfd * input_bfd;
for (input_bfd = link_info.input_bfds;
input_bfd != NULL;
input_bfd = input_bfd->link_next)
{
struct elf_obj_tdata *tdata = ((input_bfd) -> tdata.elf_obj_data);
if (bfd_get_format (input_bfd) == bfd_object && tdata != NULL)
{
_bfd_dwarf2_cleanup_debug_info(input_bfd,
&tdata->dwarf2_find_line_info);
tdata->dwarf2_find_line_info = NULL;
}
}
}
--
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/16720] wrong overflow check in R_MIPS_HI16
https://sourceware.org/bugzilla/show_bug.cgi?id=16720 --- Comment #1 from ma.jiang at zte dot com.cn --- Created attachment 7479 --> https://sourceware.org/bugzilla/attachment.cgi?id=7479&action=edit linker script -- 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/16720] New: wrong overflow check in R_MIPS_HI16
https://sourceware.org/bugzilla/show_bug.cgi?id=16720
Bug ID: 16720
Summary: wrong overflow check in R_MIPS_HI16
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: ma.jiang at zte dot com.cn
Created attachment 7478
--> https://sourceware.org/bugzilla/attachment.cgi?id=7478&action=edit
source file
There is a overflow check in mips ld.
=
=
===
if (r_type == R_MIPS16_HI16)
value = mips_elf_high (addend + gp - p - 4);
else
value = mips_elf_high (addend + gp - p);
overflowed_p = mips_elf_overflow_p (value, 16);
=
=
===
This check might have some problems when "addend + gp - p" is a negative
number.In my cases, I got "addend + gp - p=-132666256".This number should
be ok
for a "R_MIPS16_HI16+R_MIPS16_LO16" as it obviously could be put into a
32bits-signed-int.
But, the ld throw a overflow error. First, it get a value=63512 from
mips_elf_high, then it check if this value could be put into a
16bits-signed-int in mips_elf_overflow_p. And of course, 63512 can not be p
ut
into a 16bits-signed-int.So，a wrong overflow error is generated fin
ally.
In my opinion, we only need to check whether "addend + gp - p" could be put
into a 32bits-signed-int in R_MIPS16_HI16. Because, a 32bits-signed-int can
be
expressed correctly by R_MIPS16_HI16+R_MIPS16_LO16. The code could be like:
bfd_vma offset;
if (r_type == R_MIPS16_HI16)
{
value = mips_elf_high (addend + gp - p - 4);
offset = addend + gp - p - 4;
}
else
{
value = mips_elf_high (addend + gp - p);
offset = addend + gp - p;
}
overflowed_p = mips_elf_overflow_p (offset, 32);
This bug can be reproduced by attached files, using commands like:
gcc ldtest.c -o ldtest -Wl,-T bug.lds -static -fPIC
--
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/16202] ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)
https://sourceware.org/bugzilla/show_bug.cgi?id=16202 --- Comment #4 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #1) > Created attachment 7337 [details] Proposed patch === This patch can solve the abs8 problem.In fact,I have considered a simliar fix. The reason that I choose to fix the ABS8 branch not the top one, is That I found many branches(eg, R_ARM_THM_ABS5) had already refetched the addend. I think it's more safe to follow their way--fix the problem and make sure not to throw new problems.Changing the top addend may touch many other branches, I could not make sure all of them were ok with the change. Today, after reading all branches of elf32_arm_final_link_relocate again, I think it is ok to change the top addend. But still there are something need to discuss. First, some relocs require to read more bytes than its bitsize shows.For example,R_ARM_ABS12 is set to the first byte of the instruction, and its bitsize is 12. So, using bfd_get_16 to get addend is not right. R_ARM_ABS12 is ok, as it seems only used by vxworks,and does not get addend from instructions(globals->use_rel=0). For other similar relocs such as R_ARM_ALU_PCREL7_0,R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS, addend is refeteched in their branches. So, This is just a hidden danger for now.But we should pay attention. Second, some relocs (eg,R_ARM_THM_JUMP6) refecthed the addend. They will not need the refetch process any more if the proposed patch applied. It will be better if the patch do some clean for this, I think. At last ,I think the Root Cause of this problem is the reloc_howto mechanism. This mechanism failed to provide a clear abstraction for relocations, as it exposed too many details. As a result, almost every reloc process branch has to do some special things.In fact, the only thing that caller should know and set is the relocation type. The reloc_howto mechanism should automaticlly finished remaining dirty work such as adjusting the mask for big endian target, extracting the addend, computing the reloc result, and Writing back results. Adding some new callbacks for reloc_howto_struct can do the job, this is not very hard theoretically, but the real amount of work could be horrible. -- 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/16202] ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)
https://sourceware.org/bugzilla/show_bug.cgi?id=16202 --- Comment #3 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #2) > Hi Ma, I do not think that refetching the addend in the ABS8 and ABS16 > cases is the right thing to do. There could be other relocations that are > affected by the same problem. Instead I think that the correct thing to do > is to fetch the addend using the proper bfd_get_XX macro in the first place. > Please could you try out the uploaded patch and let me know if it works for > you ? Cheers Nick == Hi Nick, Thanks for the reply. I have carefully read the proposed patch. -- 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/16202] ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)
https://sourceware.org/bugzilla/show_bug.cgi?id=16202 ma.jiang at zte dot com.cn changed: What|Removed |Added Component|gas |ld -- 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 gas/16202] New: ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)
https://sourceware.org/bugzilla/show_bug.cgi?id=16202 Bug ID: 16202 Summary: ABS8 and ABS16 get wrong addend on ARM-ELF (big endian) Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ma.jiang at zte dot com.cn on ARM-ELF , in function elf32_arm_final_link_relocate, addend is get from : addend = bfd_get_32 (input_bfd, hit_data) & howto->src_mask; .There is a little problem, becasue howto->scr_mask is a constant that designed for little endian. for example , in the testcase in gas testsuit: .syntax unified .byte x -128 .byte x +255 .short y -32768 .short y +65535 the first ABS8 reloc for x should get a addend -128.But on big endian ARM, "bfd_get_32 (input_bfd, hit_data)" get a 0x80ff8000, and with a howto->src_mask=0xff, the final addend is 0. in the ABS8 branch, the addend is used directly. case R_ARM_ABS8: value += addend; /* There is no way to tell whether the user intended to use a signed or unsigned addend. When checking for overflow we accept either, as specified by the AAELF. */ if ((long) value > 0xff || (long) value < -0x80) return bfd_reloc_overflow; bfd_put_8 (input_bfd, value, hit_data); return bfd_reloc_ok; Finally, a 0 is put into the object file, which of course is totally wrong. ABS16 has the same problem. Fix for this problem is quite strait-forward. IN ABS8/ABS16 branch, we can fetch addend once more using correct bfd_get_8/bfd_get_16, as following codes : case R_ARM_ABS8: addend = bfd_get_8 (input_bfd, hit_data); /*fectch addend again with bfd_get_8 */ value += addend; /* There is no way to tell whether the user intended to use a signed or unsigned addend. When checking for overflow we accept either, as specified by the AAELF. */ if ((long) value > 0xff || (long) value < -0x80) return bfd_reloc_overflow; bfd_put_8 (input_bfd, value, hit_data); return bfd_reloc_ok; . -- 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
