[Bug ld/20823] invalid "tail +16c" still used

[ma.jiang at zte dot com.cn]

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=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

[ma.jiang at zte dot com.cn]

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=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

[ma.jiang at zte dot com.cn]

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=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

[ma.jiang at zte dot com.cn]

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=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

[ma.jiang at zte dot com.cn]

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=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 gas/20803] Sparc R_SPARC_32 reloc with miss-align offset.

[chrisj at rtems dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20803

--- Comment #2 from Chris Johns  ---
(In reply to Nick Clifton from comment #1)
> Created attachment 9623 [details]
> Proposed patch

Thank you for the quick turn around.

> 
>   Please could you try out this patch and let me know if it is enough to
> solve the problem.
> 

Yes, this solves the problem we are seeing.

>   I am not sure if this approach is the correct way to fix the issue, but it
> does seem to be the simplest.  As far as I can tell, the relocs in the
> .eh_frame section can eb unaligned, so using R_SPARC_UA32 seems to be the
> correct thing to do.  I did look to see if I could enable
> sparc_no_align_cons when fixing the output for the .eh_frame section, but I
> could not find an easy way to do this. Hence I went for a hack based on the
> section name.  Not very subtle, but if it works then that is enough for now.

I also had a look and felt any change was a potential issue for some other
reason I would not be aware of. We will use this patch in RTEMS until the next
binutils release.

Thank you.

-- 
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/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20800

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.28

--- Comment #10 from H.J. Lu  ---
Fixed for 2.28.

-- 
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/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20800

--- Comment #9 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9d734efa1034d266249751978f95a686ec9d19c6

commit 9d734efa1034d266249751978f95a686ec9d19c6
Author: H.J. Lu 
Date:   Mon Nov 14 10:13:03 2016 -0800

Also check GOT PLT for R_X86_64_PLTOFF64

Since "-z now" replaces PLT with GOT PLT, we should also check GOT PLT
for R_X86_64_PLTOFF64 relocation.

bfd/

PR ld/20800
* elf64-x86-64.c (elf_x86_64_relocate_section): Also check
plt_got.offset for R_X86_64_PLTOFF64.

ld/

PR ld/20800
* testsuite/ld-x86-64/pr20800a.S: New file.
* testsuite/ld-x86-64/pr20800b.S: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/20800 test.

-- 
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/20811] strip not stripped in the dynamic table

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20811

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi rm beer,

> in the .dynamic of SHDR always have the pointer to SYMTAB(.symtab) and
> STRTAB(.strtab), if access from .dynamic in ELF or _DYNAMIC[] in C++, this
> have a old pointer that not have nothing in the memory, can produce a
> segmentation of fault.

Please could you provide an example of how to recreate this problem.  I tried a
couple of tests locally but could not create a binary that would seg-fault.

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 binutils/20814] DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6 Section)

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20814

--- Comment #2 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=35fd2ddeb1d90f1750401cfb6d01fe055656b88d

commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d
Author: Rudy 
Date:   Mon Nov 14 16:30:45 2016 +

Generate correct hint value for IDATA6.

PR binutils/20814
* dlltool.c (struct export): Remove hint field.
(make_one_lib_file): Store the ordinal value for IDATA6 not the
hint.
(gen_lib_file): Delete reference to hint field.
(mangle_defs): Delete computation of hint field.

-- 
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/20814] DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6 Section)

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20814

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-14
 CC||nickc at redhat dot com
 Ever confirmed|0   |1

--- Comment #3 from Nick Clifton  ---
Hi Rudy,

  Thanks for the bug report and patch details.  I have applied the changes that
you suggested.  Please could you confirm that the dlltool now works properly ?

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/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20800

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from H.J. Lu  ---
[hjl@gnu-6 pr20800]$ cat test.c
#include 
int main(void) {
printf("Hello World");
return 0;
}
[hjl@gnu-6 pr20800]$ gcc -fpie -mcmodel=large -fno-builtin test.c 
[hjl@gnu-6 pr20800]$ gcc -pie test.o -Wl,-z,now 
/usr/local/bin/ld: test.o(.text+0x36): unresolvable R_X86_64_PLTOFF64
relocation against symbol `printf@@GLIBC_2.2.5'
/usr/local/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
[hjl@gnu-6 pr20800]$

-- 
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

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20815

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
(In reply to ma.jiang from comment #0)

>   Attached "segment-check.patch" adds a check in make_mapping(in elf.c) , it
> should be enough to fix the bug.

When I try to unzip the attachment I get:

Archive:  attach.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.

Could you upload the attachment again please ?

-- 
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/20675] [metag] internal error cross-compiling static programs

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20675

--- Comment #5 from Nick Clifton  ---
Created attachment 9629
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9629=edit
Proposed patch

Hi Wbx,

  Thanks very much.  I can now reproduce the problem, although I am not sure
now it should be resolved.  At issue is the fact that the libc.a library
contains relocations that set up entries in the PLT, but the PLT is only used
when creating a dynamic executable, not a static one.  You are linking with
"-static" specified on the command line, so clearly the intent is to create a
static executable.

  There is a bug in the linker, in that it should have produced an informative
error message and then exited with a non-zero return code, rather than calling
abort.  But I do not think that the linker is doing anything fundamentally
wrong.  You are asking it to create a static executable, but giving it shared
libraries to link.  The real bug, IMHO, is the creation of what appears to be a
static library - libc.a - but which actually contains shared library code.

  The uploaded patch will fix the linker, so that an error message like this is
displayed:

  ld:./libc.a(herrno.os)(.text): shared library symbol _h_errno encountered
whilst performing a static link
  ld: final link failed: Nonrepresentable section on output

If you are happy with this change then I will check it in.  I am not sure
however what should be done about libc.a.  I think that you need to investigate
how it was created in the first place.

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