R_PARISC_TLS_DTPOFF32 reloc handling

  This is the trivial patch mentioned in 
https://sourceware.org/ml/binutils/2018-04/msg00237.html

OK to apply?
  

On 04/20/2018 11:36 PM, Alan Modra wrote:
> This is the trivial patch mentioned in 
> https://sourceware.org/ml/binutils/2018-04/msg00237.html
> 
> OK to apply?

This looks correct to me. However, I'd want Dave to confirm that this
doesn't break anything. I can't see how it would, we really have to
add the addend here.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
 
> diff --git a/ChangeLog b/ChangeLog
> index 6b17507..cda8bb1 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2018-04-21  Alan Modra  <amodra@gmail.com>
> +
> +	* sysdeps/hppa/dl-machine.h (elf_machine_rela): Add
> +	R_PARISC_TLS_DTPOFF32 reloc addend.
> +
>  2018-04-20  Joseph Myers  <joseph@codesourcery.com>
>  
>  	* sysdeps/unix/sysv/linux/alpha/bits/termios.h [__USE_MISC]
> diff --git a/sysdeps/hppa/dl-machine.h b/sysdeps/hppa/dl-machine.h
> index 3a57c7e..5f4e0d3 100644
> --- a/sysdeps/hppa/dl-machine.h
> +++ b/sysdeps/hppa/dl-machine.h
> @@ -690,7 +690,7 @@ elf_machine_rela (struct link_map *map,
>        /* During relocation all TLS symbols are defined and used.
>  	 Therefore the offset is already correct.  */
>        if (sym != NULL)
> -	*reloc_addr = sym->st_value;
> +	*reloc_addr = sym->st_value + reloc->r_addend;
>        return;
>  
>      case R_PARISC_TLS_TPREL32:
>
  

On 2018-04-26 12:04 AM, Carlos O'Donell wrote:
> On 04/20/2018 11:36 PM, Alan Modra wrote:
>> This is the trivial patch mentioned in
>> https://sourceware.org/ml/binutils/2018-04/msg00237.html
>>
>> OK to apply?
> This looks correct to me. However, I'd want Dave to confirm that this
> doesn't break anything. I can't see how it would, we really have to
> add the addend here.
>
There are some regressions in the test results which need 
investigation.  Some tests are
generating segmentation faults.  The build on 20180330 was done with 
Debian gcc-7.  The
20180423 build was done with trunk binutils and gcc.

Dave
  

On 2018-04-26 8:05 AM, John David Anglin wrote:
> On 2018-04-26 12:04 AM, Carlos O'Donell wrote:
>> On 04/20/2018 11:36 PM, Alan Modra wrote:
>>> This is the trivial patch mentioned in
>>> https://sourceware.org/ml/binutils/2018-04/msg00237.html
>>>
>>> OK to apply?
>> This looks correct to me. However, I'd want Dave to confirm that this
>> doesn't break anything. I can't see how it would, we really have to
>> add the addend here.
>>
> There are some regressions in the test results which need 
> investigation.  Some tests are
> generating segmentation faults.  The build on 20180330 was done with 
> Debian gcc-7.  The
> 20180423 build was done with trunk binutils and gcc.
The regressions don't occur with Debian gcc 7.3.0-16, so I believe the 
change is okay.

Dave
  

On 2018-04-28 3:28 PM, John David Anglin wrote:
> On 2018-04-26 8:05 AM, John David Anglin wrote:
>> On 2018-04-26 12:04 AM, Carlos O'Donell wrote:
>>> On 04/20/2018 11:36 PM, Alan Modra wrote:
>>>> This is the trivial patch mentioned in
>>>> https://sourceware.org/ml/binutils/2018-04/msg00237.html
>>>>
>>>> OK to apply?
>>> This looks correct to me. However, I'd want Dave to confirm that this
>>> doesn't break anything. I can't see how it would, we really have to
>>> add the addend here.
>>>
>> There are some regressions in the test results which need 
>> investigation.  Some tests are
>> generating segmentation faults.  The build on 20180330 was done with 
>> Debian gcc-7.  The
>> 20180423 build was done with trunk binutils and gcc.
> The regressions don't occur with Debian gcc 7.3.0-16, so I believe the 
> change is okay.
I created a bugzilla report:
https://sourceware.org/bugzilla/show_bug.cgi?id=23174

Signal handler returns are broken.  Alan, this has nothing to do with 
your change.

Dave