This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: LD and ARM interworking


Sorry, that doesn't work. Looks like .glue sections have been already
inserted at that point so moving the check inside the conditional for those
sections does the job as far as data only objects go. I've attached the diff
I ended up with. Incidentally it seems that the first parameter to the
bfd_get_section_flags macro is ignored, I thought the code was a little
clearer using ibfd instead of sec->owner. Just personal taste really :)

The issue I mentioned is a touch odd. If you link a series of objects with
differing interwork flags i.e.

gcc -mthumb (non-interwork).o (interwork).o (non-interwork).o -o test.elf

a warning only gets generated for the third object so it appears that
linking an object with interwork flag sets that flag for the output elf.
This results in somewhat confusing interwork warnings at link time.

It seems to me that this would be best handled by gcc telling ld what the
intended flags for the output are, and ld not setting the output flags when
it encounters an interwork object.

I'm afraid I discovered another bug with the latest sources while playing
with this, if I use an expression like this in the linker script :-

__text_start = DEFINED (__gba_multiboot) ? 0x2000000 : 0x8000000;

AND request a generated mapfile, ld blows up when it encounters the
conditional expression.

sorry to be a pain

Dave

> -----Original Message-----
> From: Nick Clifton [mailto:nickc@redhat.com]
> Sent: 09 March 2004 12:36
> To: Dave Murphy
> Cc: binutils@sources.redhat.com
> Subject: Re: LD and ARM interworking
>
>
> Hi Dave,
>
> > I have a problem with an arm-elf targetted tool chain I'm buildling with
> > respect to interworking. I've been attempting to figure out how
> to turn off
> > the interworking warning when linking objects that only contain
> data since
> > this makes no sense when there is no code to interwork. I'm using the
> > release source tarballs of binutils 2.14, gcc 3.3.3 & newlib 1.12.0.
> >
> > In the course of this I've discovered that LD has a serious
> issue with the
> > mixing of the two types of object. It appears that if one object has the
> > interworking flag set then the output elf gets that flag set.
> This results
> > in warnings about blah.o does not support interworking, whereas blah.elf
> > does.
> >
> > When the intention was to compile an executable with
> interworking code, this
> > is correct. However, when the intention was for
> non-interworking code, this
> > behaviour is wrong. It appears that LD will *never* produce the opposite
> > warning 'blah.o supports interworking, whereas blah.elf does not'
> >
> > Is there a way of specifying that the intent is to link only objects
> > containing non-interworking code and produce the correct
> warnings for that
> > case when interworked objects are linked in error?
>
> Not at the moment no, but patches can always be developed.  For
> example for the one appended below.  Would you care to try it and see
> if it works ?
>
> Cheers
>         Nick
>
> 2004-03-09  Nick Clifton  <nickc@redhat.com>
>
> 	* elf32-arm.h (elf32_arm_merge_private_bfd_data): Skip most checks
> 	if the input bfd does not contain any code.
>
> Index: bfd/elf32-arm.h
> ===================================================================
> RCS file: /cvs/src/src/bfd/elf32-arm.h,v
> retrieving revision 1.120
> diff -c -3 -p -r1.120 elf32-arm.h
> *** bfd/elf32-arm.h	23 Jan 2004 16:51:48 -0000	1.120
> --- bfd/elf32-arm.h	9 Mar 2004 12:32:00 -0000
> *************** elf32_arm_merge_private_bfd_data (ibfd,
> *** 2430,2452 ****
>        not, its flags may not have been initialised either, but it
>        cannot actually cause any incompatibility.  Do not short-circuit
>        dynamic objects; their section list may be emptied by
> !      elf_link_add_object_symbols.  */
>
>     if (!(ibfd->flags & DYNAMIC))
>       {
>         bfd_boolean null_input_bfd = TRUE;
>
>         for (sec = ibfd->sections; sec != NULL; sec = sec->next)
>   	{
>   	  /* Ignore synthetic glue sections.  */
>   	  if (strcmp (sec->name, ".glue_7")
>   	      && strcmp (sec->name, ".glue_7t"))
> ! 	    {
> ! 	      null_input_bfd = FALSE;
> ! 	      break;
> ! 	    }
>   	}
> !       if (null_input_bfd)
>   	return TRUE;
>       }
>
> --- 2430,2460 ----
>        not, its flags may not have been initialised either, but it
>        cannot actually cause any incompatibility.  Do not short-circuit
>        dynamic objects; their section list may be emptied by
> !      elf_link_add_object_symbols.
>
> +      Also check to see if there are no code sections in the input.
> +      In this case there is no need to check for code specific flags.
> +      XXX - do we need to worry about floating-point format compatability
> +      in data sections ?  */
>     if (!(ibfd->flags & DYNAMIC))
>       {
>         bfd_boolean null_input_bfd = TRUE;
> +       bfd_boolean only_data_sections = TRUE;
>
>         for (sec = ibfd->sections; sec != NULL; sec = sec->next)
>   	{
>   	  /* Ignore synthetic glue sections.  */
>   	  if (strcmp (sec->name, ".glue_7")
>   	      && strcmp (sec->name, ".glue_7t"))
> ! 	    null_input_bfd = FALSE;
> !
> ! 	  if ((bfd_get_section_flags (sec->owner, sec)
> ! 	       & (SEC_LOAD | SEC_CODE | SEC_HAS_CONTENTS))
> ! 	      == (SEC_LOAD | SEC_CODE | SEC_HAS_CONTENTS))
> ! 	    only_data_sections = FALSE;
>   	}
> !
> !       if (null_input_bfd || only_data_sections)
>   	return TRUE;
>       }
>
>

Attachment: elf32-arm.h.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]