[Bug binutils/24281] Failed with “thin archive” if it contain subdir's object file
https://sourceware.org/bugzilla/show_bug.cgi?id=24281 --- Comment #3 from lol lol --- Hi Nick, Q. Hmm, you do realise that copying a thin library in this way is essentially the same thing as just copying it normally, right? A. Yes. It was chosen for simplicity. Anyway, it shouldn't fail. Can you agree? Q. The question is, what would you expect objcopy to do if you also had one or more of its transformation options enabled as well. For example, what should this do: objcopy --strip-debug out.a out_copy.a A. I expect similar behavior as for other "non-thin" object files. Why not to do "--strip-debug" for all included files recursively? It may be done in-place, or done with a copy. Q. Would you expect objcopy to create new versions of all of the object files linked to within out.a, with the debugging stripped from the new versions ? If so, what names should be given to these new object files ? Or how about: objcopy out.a subdir/copy.a Would you expect objcopy to leave the object files intact but to rename the links inside copy.a so that they are valid for the new location of the thin library ? A. In this case (case, when objcopy pretends to change object files), we may simply notify user, that object files will be rewritten and wait for the confirmation. Q. It seems to me that the easiest thing to do would be to just reject attempts to objcopy thin archives. But maybe this is too draconian. Would you be happy if an in-place copy of a thin archive was allowed, but transformations, or relocations were refused? A. I think, it is not a bad idea to simply disallow objcopy for thin archives till the moment, when it will be supported (in alternative future). I think it is not of "draconian" attempt. This way, user of this magic tool will not be confused at all. Thank you! WBR, lol lol -- 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/24281] Failed with “thin archive” if it contain subdir's object file
https://sourceware.org/bugzilla/show_bug.cgi?id=24281 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f5f20315116c43110c058ec9d787e20f901309f2 commit f5f20315116c43110c058ec9d787e20f901309f2 Author: Nick Clifton Date: Mon Mar 4 13:11:08 2019 + Stop objcopy from attempting to copy thin archives. PR 24281 * objcopy.c (copy_archive): Do not copy thin archives. -- 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/24281] Failed with “thin archive” if it contain subdir's object file
https://sourceware.org/bugzilla/show_bug.cgi?id=24281 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- Hi lol lol, Great - in which case I have applied a patch to stop objcopy from copying thin archives - for now... Cheers Nick -- 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/24302] New: When DF_BIND_NOW the dt_tlsdesc_got should not be used
https://sourceware.org/bugzilla/show_bug.cgi?id=24302
Bug ID: 24302
Summary: When DF_BIND_NOW the dt_tlsdesc_got should not be used
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: wangtao42 at huawei dot com
Target Milestone: ---
Hi All,
I produced a problem, and after debugging it seems that in
elfNN_aarch64_finish_dynamic_sections the value of htab->dt_tlsdesc_got should
be checked. If the htab->dt_tlsdesc_got is -1, then htab->root.sgot->contents
should not add it, otherwise this code will overwrite the contents of the
previous byte. The maybe-error code is as follows:
if (htab->tlsdesc_plt)
{
bfd_put_NN (output_bfd, (bfd_vma) 0,
htab->root.sgot->contents + htab->dt_tlsdesc_got);
memcpy (htab->root.splt->contents + htab->tlsdesc_plt,
elfNN_aarch64_tlsdesc_small_plt_entry,
sizeof (elfNN_aarch64_tlsdesc_small_plt_entry));
This is aarch64 backend, and the only assignment of dt_tlsdesc_got is limited
by DF_BIND_NOW. when linking with "-z now", this code won't be executed
/* If we're not using lazy TLS relocations, don't generate the
GOT entry required. */
if (!(info->flags & DF_BIND_NOW))
{
htab->dt_tlsdesc_got = htab->root.sgot->size;
htab->root.sgot->size += GOT_ENTRY_SIZE;
}
So anyone can explain this? Is htab->dt_tlsdesc_got needed to check validaty
before using in elfNN_aarch64_finish_dynamic_sections?
Because it needs many object file to reproduce this problem, I can't upload a
testcase. I'll be very grateful if someone can explain the code.
Thanks
--
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
