IA-64: Fix linker error with --no-keep-memory.

Message ID 20180226220648.948-1-jimw@sifive.com
State New
Headers show
Series
  • IA-64: Fix linker error with --no-keep-memory.
Related show

Commit Message

Jim Wilson Feb. 26, 2018, 10:06 p.m.
Fixes for the --no-keep-memory bug reported in PR 15904.  Setting the changed_*
vars prevents us from freeing modified memory.

Tested with binutils, gas, and ld make check.  There were no regressions.

Committed.

Jim

	bfd/
	PR 15904
	* elfnn-ia64.c (elfNN_ia64_relax_section): After ia64_elf_relax_brl
	call, set changed_contents and changed_relocs.  Likewise after
	successful ia64_elf_relax_br call.
---
 bfd/elfnn-ia64.c | 6 ++++++
 1 file changed, 6 insertions(+)

-- 
2.14.1

Comments

Jim Wilson Feb. 27, 2018, 8:47 p.m. | #1
On 02/26/2018 02:06 PM, Jim Wilson wrote:
> 	bfd/

> 	PR 15904

> 	* elfnn-ia64.c (elfNN_ia64_relax_section): After ia64_elf_relax_brl

> 	call, set changed_contents and changed_relocs.  Likewise after

> 	successful ia64_elf_relax_br call.


I got a request to backport this to the binutils-2.30 branch.  I'm not 
sure what the rules are for backporting patches to release branches for 
binutils.  Can I just approve this myself?  Or do I need the release 
maintainer (Nick?) to approve it?

Jim
Nick Clifton Feb. 28, 2018, 10:41 a.m. | #2
Hi Jim,

>>     bfd/

>>     PR 15904


> I got a request to backport this to the binutils-2.30 branch.  I'm not sure what the rules are for backporting patches to release branches for binutils.  Can I just approve this myself?  Or do I need the release maintainer (Nick?) to approve it?


The rules are:

  * If it is a new feature then you need the approval of a
    global maintainer, and the answer will probably be "no".

  * Otherwise, if we are not in the build up to a release
    then the normal patch approval rules apply.  So in the
    case of the fix for PR 15904, since you are the IA64 
    maintainer you can approve it yourself.

  * Otherwise, when we are in the run up to a new release,
    all patches should be run past the Release Manager just
    so that he/she/they can keep a handle on how the release
    is shaping up.

Cheers
  Nick
Jason Duerstock Feb. 28, 2018, 11:20 a.m. | #3
Can enabling --gc-sections for IA64 be backported as well, please?:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e8d06db1a6e63e0da80035114dbfefeabf63d87

Thanks,

Jason


On Wed, Feb 28, 2018 at 5:41 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Jim,

>

>>>     bfd/

>>>     PR 15904

>

>> I got a request to backport this to the binutils-2.30 branch.  I'm not sure what the rules are for backporting patches to release branches for binutils.  Can I just approve this myself?  Or do I need the release maintainer (Nick?) to approve it?

>

> The rules are:

>

>   * If it is a new feature then you need the approval of a

>     global maintainer, and the answer will probably be "no".

>

>   * Otherwise, if we are not in the build up to a release

>     then the normal patch approval rules apply.  So in the

>     case of the fix for PR 15904, since you are the IA64

>     maintainer you can approve it yourself.

>

>   * Otherwise, when we are in the run up to a new release,

>     all patches should be run past the Release Manager just

>     so that he/she/they can keep a handle on how the release

>     is shaping up.

>

> Cheers

>   Nick

>

>
Nick Clifton Feb. 28, 2018, 2:14 p.m. | #4
Hi Jason,

> Can enabling --gc-sections for IA64 be backported as well, please?:


Done.

Note - just because patches are being applied to the 2.30 branch, that
does not mean that we are guaranteeing to make a 2.30.1 release.  (This
may not matter to you of course).  Normally a point release would only
be made if there are one or more really serious bugs in the original
release that definitely need to be fixed.

Cheers
  Nick
Jason Duerstock Feb. 28, 2018, 2:16 p.m. | #5
Duly noted.

Thanks,

Jason

On Wed, Feb 28, 2018 at 9:14 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Jason,

>

>> Can enabling --gc-sections for IA64 be backported as well, please?:

>

> Done.

>

> Note - just because patches are being applied to the 2.30 branch, that

> does not mean that we are guaranteeing to make a 2.30.1 release.  (This

> may not matter to you of course).  Normally a point release would only

> be made if there are one or more really serious bugs in the original

> release that definitely need to be fixed.

>

> Cheers

>   Nick

>

Patch

diff --git a/bfd/elfnn-ia64.c b/bfd/elfnn-ia64.c
index 595316dc11..84b1af1456 100644
--- a/bfd/elfnn-ia64.c
+++ b/bfd/elfnn-ia64.c
@@ -593,6 +593,9 @@  elfNN_ia64_relax_section (bfd *abfd, asection *sec,
 		     1, change it to slot 2.  */
 		  if ((irel->r_offset & 3) == 1)
 		    irel->r_offset += 1;
+
+		  changed_contents = TRUE;
+		  changed_relocs = TRUE;
 		}
 
 	      continue;
@@ -607,6 +610,9 @@  elfNN_ia64_relax_section (bfd *abfd, asection *sec,
 
 	      /* Make the relocation offset point to slot 1.  */
 	      irel->r_offset = (irel->r_offset & ~((bfd_vma) 0x3)) + 1;
+
+	      changed_contents = TRUE;
+	      changed_relocs = TRUE;
 	      continue;
 	    }