Re: Special ELF section flags vs. linker-specified bfd flags

[Richard Sandiford <richard at codesourcery dot com>]

"H. J. Lu" <hjl@lucon.org> writes:
> On Wed, Oct 18, 2006 at 11:15:32AM +0100, Richard Sandiford wrote:
>> There seems to be a bad interaction between:
>> 
>> bfd/
>> 2006-04-26  H.J. Lu  <hongjiu.lu@intel.com>
>> 
>> 	PR binutils/2593
>> 	* elf.c (_bfd_elf_new_section_hook): Don't set section ELF type
>> 	and flags if its BFD flags have been set.
>> 	(_bfd_elf_init_private_section_data): Don't copy the output ELF
>> 	section type from input if it has been set to something
>> 	different.
>> 
>> and:
>> 
>> ld/
>> 2006-08-01  H.J. Lu  <hongjiu.lu@intel.com>
>> 
>> 	* ldlang.c (init_os): Add flags. Replace bfd_make_section with
>> 	bfd_make_section_with_flags.
>> 	(exp_init_os): Updated.
>> 	(lang_add_section): Call init_os with flags.
>> 	(map_input_to_output_sections): Likewise.
>> 
>> The _bfd_elf_new_section_hook hunk was:
>> 
>>    bed = get_elf_backend_data (abfd);
>>    sec->use_rela_p = bed->default_use_rela_p;
>>  
>> -  /* When we read a file, we don't need section type and flags unless
>> -     it is a linker created section.  They will be overridden in
>> -     _bfd_elf_make_section_from_shdr anyway.  */
>> -  if (abfd->direction != read_direction
>> +  /* When we read a file or section BFD flags have been set, we don't
>> +     need section type and flags unless it is a linker created section.
>> +     They will be overridden in _bfd_elf_make_section_from_shdr
>> +     anyway.  */
>> +  if ((!sec->flags && abfd->direction != read_direction)
>>        || (sec->flags & SEC_LINKER_CREATED) != 0)
>>      {
>>        ssect = (*bed->get_sec_type_attr) (abfd, sec);
>> 
>> but the later linker change makes init_os propagate the input section's
>> bfd flags to the new output section.  We therefore skip the get_sec_type_attr
>> stuff for normal sections, even though the user hasn't overridden the flags.
>> This in turn means we miss target-specific SHF_* flags that have no
>> corresponding bfd section flag.
>> 
>> This caused reloc-1-rel.d and reloc-1-n32.d to fail on MIPS.  This loop:
>
> Can I see the failure with a cross binutils?

Yeah, target mips64-linux-gnu.

Richard