[Bug ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 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=597344c9a4a110b662ed04fe115e6f887b42d366

commit 597344c9a4a110b662ed04fe115e6f887b42d366
Author: H.J. Lu 
Date:   Sun Jun 7 14:48:13 2020 -0700

ld: Pass $LFLAGS to PR ld/21703 shared test

$LFLAGS is needed for -shared test.  This fixes

FAIL: PR ld/21703 shared

for tic6x-*-elf.

* testsuite/ld-elf/shared.exp: Pass $LFLAGS to PR ld/21703
shared test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26083] cris linker generate zero sized PLTRELSZ

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Hans-Peter Nilsson from comment #1)
> 
> I don't mind to have it that way, but I'm not sure it's as easy to remove as
> just an extra if-clause in elf_cris_finish_dynamic_sections, as room has to
> be allocated for it in elf_cris_finish_dynamic_sections, when it's value is
> unknown.

I am removing code duplication in ELF linker.  One of consequence is to remove
optional

 0x0002 (PLTRELSZ)   0 (bytes)
 0x0014 (PLTREL) RELA
 0x0017 (JMPREL) 0x194

from cris linker output when they aren't needed.  I will leave this bug
open and post a fix after my ELF linker cleanup has been merged into
master branch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26083] cris linker generate zero sized PLTRELSZ

[hp at sourceware dot org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Hans-Peter Nilsson  ---
(In reply to H.J. Lu from comment #0)
...
>  0x0002 (PLTRELSZ)   0 (bytes)  Is it really needed?
>  0x0014 (PLTREL) RELA
>  0x0017 (JMPREL) 0x194
...

I'd say yes, according to the 2001 gABI draft I see at
.
 While DT_PLTRELSZ is listed as optional in the table named "Figure 5-10:
Dynamic Array Tags, d_tag", there's also a description in the section after
that, which says "If an entry of type DT_JMPREL is present, a DT_PLTRELSZ must
accompany it".

Pragmatically, I see the consensus of the rest of the world is that it's
actually optional and its absence is to be treated as the value 0, in
particular since your 2017 commit to glibc to that effect. :)

I don't mind to have it that way, but I'm not sure it's as easy to remove as
just an extra if-clause in elf_cris_finish_dynamic_sections, as room has to be
allocated for it in elf_cris_finish_dynamic_sections, when it's value is
unknown.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26090] is_relocatable_executable isn't handled correctly for PIC output

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|is_relocatable_executable   |is_relocatable_executable
   |isn't handled correctly |isn't handled correctly for
   ||PIC output

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26090] is_relocatable_executable isn't handled correctly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|Incorrect exclude.exp   |is_relocatable_executable
   ||isn't handled correctly

--- Comment #1 from H.J. Lu  ---
bfd_boolean
bfd_elf_link_record_dynamic_symbol (struct bfd_link_info *info,
struct elf_link_hash_entry *h)
{
  if (h->dynindx == -1)
{
  struct elf_strtab_hash *dynstr;
  char *p;
  const char *name;
  size_t indx;

  /* XXX: The ABI draft says the linker must turn hidden and
 internal symbols into STB_LOCAL symbols when producing the
 DSO. However, if ld.so honors st_other in the dynamic table,
 this would not be necessary.  */
  switch (ELF_ST_VISIBILITY (h->other))
{
case STV_INTERNAL:
case STV_HIDDEN:
  if (h->root.type != bfd_link_hash_undefined
  && h->root.type != bfd_link_hash_undefweak)
{
  h->forced_local = 1;
  if (!elf_hash_table (info)->is_relocatable_executable)
    Should bfd_link_pic (info) also return TRUE?
return TRUE;
}

default:
  break;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26090] New: Incorrect exclude.exp

[hjl.tools at gmail dot com]

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

Bug ID: 26090
   Summary: Incorrect exclude.exp
   Product: binutils
   Version: 2.35 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

exclude.exp has

if { [ld_link $ld tmpdir/exclude.so "--exclude-libs libexclude.a --shared
tmpdir/exclude1.o -Ltmpdir -lexclude"]
 && [ld_nm $nm "-D" tmpdir/exclude.so]
 && ! [info exists nm_output(exclude_common)]
 && ! [info exists nm_output(exclude_sym)] } {
pass $test5
} else {
fail $test5
}

tic6x-elf has

  ret->elf.is_relocatable_executable = 1; 

 /* True if this target has relocatable executables, so needs dynamic
 section symbols.  */
  bfd_boolean is_relocatable_executable;

"nm -D" reports:

02001380 B _HEAP_MAX
1380 B _HEAP_START
02101380 B _STACK_START
137c b exclude_common
126c D include_sym
FAIL: ld exclude symbols from archive - --exclude-libs libexclude

It is wrong to check if exclude_common is in the dynamic symbol table
without checking its binding.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/26082] infinite loop in windmc

[joelanderson333 at gmail dot com]

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

--- Comment #10 from Joel Anderson  ---
(In reply to Ralf Habacker from comment #8)

> Can you say from which version on this behavior was changed ? 

I just tested with the executable packaged with the Windows SDK for Windows 7
(7.1) and found that it rejects the attached EOF sample. I don't have the time
to go farther back, but this suggests that this has been the functionality for
at least a very long time.

> This change means that projects using the old style would have to adjust the
> corresponding files, which for example requires additional maintenance work
> for the Mingw maintainers at opensuse to patch all affected packages and
> report this change to the corresponding projects.

Considering this hasn't been allowed in mc.exe for quite a while (since Windows
7) and resulted in an infinite loop on windmc until this patch, I suspect there
aren't many projects relying on it? Unless I have unintentionally broken
something which was previously working, in which case I do apologize.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/26088] windmc reports incorrect line numbers

[ralf.habacker at freenet dot de]

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

Ralf Habacker  changed:

   What|Removed |Added

  Attachment #12599|0   |1
is obsolete||

--- Comment #5 from Ralf Habacker  ---
Created attachment 12600
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12600=edit
0001-Corrects-the-broken-line-number-incrementation-in-th.patch (update 2)

Fixed minor issue in commit message

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/26082] infinite loop in windmc

[ralf.habacker at freenet dot de]

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

Ralf Habacker  changed:

   What|Removed |Added

 Blocks|26088   |


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=26088
[Bug 26088] windmc reports incorrect line numbers
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/26088] windmc reports incorrect line numbers

[ralf.habacker at freenet dot de]

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

Ralf Habacker  changed:

   What|Removed |Added

 Depends on|26082   |

--- Comment #4 from Ralf Habacker  ---
Update 1 of the appended patch makes this bug independent from bug 26082 and
can be applied independently.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=26082
[Bug 26082] infinite loop in windmc
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/26088] windmc reports incorrect line numbers

[ralf.habacker at freenet dot de]

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

Ralf Habacker  changed:

   What|Removed |Added

  Attachment #12598|0   |1
is obsolete||

--- Comment #3 from Ralf Habacker  ---
Created attachment 12599
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12599=edit
0001-Corrects-the-broken-line-number-incrementation-in-th.patch (update 1)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/26082] infinite loop in windmc

[ralf.habacker at freenet dot de]

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

Ralf Habacker  changed:

   What|Removed |Added

  Attachment #12596|0   |1
is obsolete||

--- Comment #9 from Ralf Habacker  ---
Comment on attachment 12596
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12596
0002-Fix-catching-EOF-in-the-Windows-resource-parser.patch

Need to be updated

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/26082] infinite loop in windmc

[ralf.habacker at freenet dot de]

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

--- Comment #8 from Ralf Habacker  ---
(In reply to Joel Anderson from comment #7)
> I do think that it is important to note that the two new patches alter
> windmc behavior to accept a file where the period is immediately followed by
> a EOF instead of a newline or carriage return and newline. 

Thanks for this pointer.

> These types of files are rejected by current versions of mc.exe, 

Can you say from which version on this behavior was changed ? 

> which is what I was using  the 'premature EOF' attachment to test against 
> myself.

This change means that projects using the old style would have to adjust the
corresponding files, which for example requires additional maintenance work for
the Mingw maintainers at opensuse to patch all affected packages and report
this change to the corresponding projects.

> While the new patches are more forgiving to the user and perhaps a better
> way to handle the scenario, they do not match mc.exe behavior. 

> I can see arguments for both cases, but just want to make sure that it is a 
> deliberate choice to deviate windmc's behavior from that of mc.exe.

I think the best would be to extend windmc with an additional command line
option to require exact mc compatibility. Projects can use this switch to make
sure that only input files compatible to mc are usable. Without this switch,
the "windmc" specific extensions would be enabled by default, but a warning is
displayed that these files may not be compatible with mc. Project maintainers
can then decide whether or not to modify these files accordingly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.