[Bug ld/20675] [metag] internal error cross-compiling static programs

2016-11-13 Thread wbx at openadk dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20675

--- Comment #4 from wbx at openadk dot org ---
Files uploaded.

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

2016-11-13 Thread jacky.chouchou at yandex dot ru
https://sourceware.org/bugzilla/show_bug.cgi?id=20814

Bug ID: 20814
   Summary: DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6
Section)
   Product: binutils
   Version: 2.27
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: jacky.chouchou at yandex dot ru
  Target Milestone: ---

I just want to report that DLLTool put wrong hint value in lib archieve (IDATA6
section).
In "make_one_lib_file" function, I see the hint value grab from
"{struct}export->hint",
instead it should grab from "{struct}export->ordinal".

Don't worry about the value in "{struct}export->ordinal", "fill_ordinals"
function take good care of it.
And "{struct}export->hint" should be erase since no function used that value
anywhere in "dlltool.c" except for
"make_one_lib_file" function.
The generate object file name in lib archive already take care by
"gen_lib_file" function.

so it should change like this in "dlltool.c" for "make_one_lib_file" function
(case IDATA6):
[-] Original: LINE 2781: int idx = exp->hint;
[+] Patch   : LINE 2781: int idx = exp->ordinal;

The patch for "dlltool.c" to remove "{struct}export->hint":
[-] typedef struct export:   LINE 785:   REMOVE THIS -> int hint;
[-] "gen_lib_file" function: LINE 3265:  REMOVE THIS -> alias_exp.hint =
exp->hint;
[-] "mangle_defs" function:  LINE 3931:  REMOVE THIS -> int hint = 0;
[-] "mangle_defs" function:  LINE 3961-3964: REMOVE ALL OF THIS ->
for (i = 0; i < d_nfuncs; i++)
if (!d_exports_lexically[i]->noname || show_allnames)
  d_exports_lexically[i]->hint = hint++;

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


[Bug binutils/20814] DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6 Section)

2016-11-13 Thread jacky.chouchou at yandex dot ru
https://sourceware.org/bugzilla/show_bug.cgi?id=20814

--- Comment #1 from Rudy  ---
{struct}export->hint.
"mangle_defs" function.
Always sequential (hint++).

{struct}export->ordinal.
"fill_ordinals" function.
Sequential IF there is no @ordinal in DEF file, not sequential IF there is
@ordinal. Mix both if there is or there aren't.

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

2016-11-13 Thread ma.jiang at zte dot com.cn
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