PATCH: Reduce size of SymbianOS DLLs

PATCH: Reduce size of SymbianOS DLLs

[Mark Mitchell]

The linker believed that SymbianOS BPABI DLLs were demand-paged, which
meant that it wanted to align segments on page-size boundaries.
However, all BPABI DLLs are post-processed before becoming something
that can actually be executed, so this is just wasted space in the
file.  I realized that when D_PAGED is clear, the linker will not try
to map the program headers, which means that some special-case code I
added for SymbianOS can be removed.

OK?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

2004-11-01  Mark Mitchell  <mark@codesourcery.com>

	* elfarm-nabi.c (elf32_arm_symbian_begin_write_processing): Clear
	D_PAGED. 
	(elf32_arm_symbian_modify_segment_map): Don't
	reset includes_filehdr and includes_phdrs here.

Index: bfd/elfarm-nabi.c
===================================================================
RCS file: /cvs/src/src/bfd/elfarm-nabi.c,v
retrieving revision 1.25
diff -c -5 -p -r1.25 elfarm-nabi.c
*** bfd/elfarm-nabi.c	19 Oct 2004 06:02:46 -0000	1.25
--- bfd/elfarm-nabi.c	1 Nov 2004 20:59:55 -0000
*************** static struct bfd_elf_special_section co
*** 972,1000 ****
  };
  
  static bfd_boolean
  elf32_arm_symbian_modify_segment_map
    PARAMS ((bfd *, struct bfd_link_info *));
  
  static bfd_boolean
  elf32_arm_symbian_modify_segment_map (abfd, info)
       bfd *abfd;
       struct bfd_link_info *info ATTRIBUTE_UNUSED;
  {
    struct elf_segment_map *m;
    asection *dynsec;
  
-   /* The first PT_LOAD segment will have the program headers and file
-      headers in it by default -- but BPABI object files should not
-      include these headers in any loadable segment.  */
-   for (m = elf_tdata (abfd)->segment_map; m != NULL; m = m->next)
-     if (m->p_type == PT_LOAD)
-       {
- 	m->includes_filehdr = 0;
- 	m->includes_phdrs = 0;
-       }
- 
    /* BPABI shared libraries and executables should have a PT_DYNAMIC
       segment.  However, because the .dynamic section is not marked
       with SEC_LOAD, the generic ELF code will not create such a
       segment.  */
    dynsec = bfd_get_section_by_name (abfd, ".dynamic");
--- 972,1009 ----
  };
  
  static bfd_boolean
  elf32_arm_symbian_modify_segment_map
    PARAMS ((bfd *, struct bfd_link_info *));
+ static void
+ elf32_arm_symbian_begin_write_processing
+   PARAMS ((bfd *, bfd_boolean));
+ 
+ static void
+ elf32_arm_symbian_begin_write_processing (abfd, linker)
+      bfd *abfd;
+      bfd_boolean linker;
+ {
+   /* BPABI objects are never loaded directly by an OS kernel; they are
+      processed by a postlinker first, into an OS-specific format.  If
+      the D_PAGED bit is set on the file, BFD will align segments on
+      page boundaries, so that an OS can directly map the file.  With
+      BPABI objects, that just results in wasted space.  In addition,
+      because we clear the D_PAGED bit, map_sections_to_segments will
+      recognize that the program headers should not be mapped into any
+      loadable segment.  */
+   abfd->flags &= ~D_PAGED;
+ }
  
  static bfd_boolean
  elf32_arm_symbian_modify_segment_map (abfd, info)
       bfd *abfd;
       struct bfd_link_info *info ATTRIBUTE_UNUSED;
  {
    struct elf_segment_map *m;
    asection *dynsec;
  
    /* BPABI shared libraries and executables should have a PT_DYNAMIC
       segment.  However, because the .dynamic section is not marked
       with SEC_LOAD, the generic ELF code will not create such a
       segment.  */
    dynsec = bfd_get_section_by_name (abfd, ".dynamic");
*************** elf32_arm_symbian_modify_segment_map (ab
*** 1022,1031 ****
--- 1031,1044 ----
    elf32_arm_symbian_link_hash_table_create
  
  #undef elf_backend_special_sections
  #define elf_backend_special_sections elf32_arm_symbian_special_sections
  
+ #undef elf_backend_begin_write_processing
+ #define elf_backend_begin_write_processing \
+     elf32_arm_symbian_begin_write_processing
+ 
  #undef elf_backend_modify_segment_map
  #define elf_backend_modify_segment_map elf32_arm_symbian_modify_segment_map
  
  /* There is no .got section for BPABI objects, and hence no header.  */
  #undef elf_backend_got_header_size

Re: PATCH: Reduce size of SymbianOS DLLs

[Richard Earnshaw]

On Mon, 2004-11-01 at 21:10, Mark Mitchell wrote:
> The linker believed that SymbianOS BPABI DLLs were demand-paged, which
> meant that it wanted to align segments on page-size boundaries.
> However, all BPABI DLLs are post-processed before becoming something
> that can actually be executed, so this is just wasted space in the
> file.  I realized that when D_PAGED is clear, the linker will not try
> to map the program headers, which means that some special-case code I
> added for SymbianOS can be removed.

Mark,

I've probably missed something subtle here, but these changes are all
being made to elfarm-nabi.c, a generic ARM file.  What is it that
prevents all these symbian-specific hooks from being called when it's
not targeting symbianos?

R.

Re: PATCH: Reduce size of SymbianOS DLLs

[Ian Lance Taylor]

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:

> On Mon, 2004-11-01 at 21:10, Mark Mitchell wrote:
> > The linker believed that SymbianOS BPABI DLLs were demand-paged, which
> > meant that it wanted to align segments on page-size boundaries.
> > However, all BPABI DLLs are post-processed before becoming something
> > that can actually be executed, so this is just wasted space in the
> > file.  I realized that when D_PAGED is clear, the linker will not try
> > to map the program headers, which means that some special-case code I
> > added for SymbianOS can be removed.
> 
> Mark,
> 
> I've probably missed something subtle here, but these changes are all
> being made to elfarm-nabi.c, a generic ARM file.  What is it that
> prevents all these symbian-specific hooks from being called when it's
> not targeting symbianos?

It's the usual BFD crock.  elf32-target.h is included twice--once by
elf32-arm.h, and once, for the Symbian stuff, by elfarm-nabi.c itself.

(I haven't tried to verify that Mark has done everything correctly,
but certainly the right framework is there).

(It would not be unreasonable to create a new file elfarm-symbian.c,
and make the appropriate functions and data structures in
elfarm-nabi.c non-static.)

Ian

Re: PATCH: Reduce size of SymbianOS DLLs

[Richard Earnshaw]

On Tue, 2004-11-02 at 14:56, Ian Lance Taylor wrote:
> Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> 
> > On Mon, 2004-11-01 at 21:10, Mark Mitchell wrote:
> > > The linker believed that SymbianOS BPABI DLLs were demand-paged, which
> > > meant that it wanted to align segments on page-size boundaries.
> > > However, all BPABI DLLs are post-processed before becoming something
> > > that can actually be executed, so this is just wasted space in the
> > > file.  I realized that when D_PAGED is clear, the linker will not try
> > > to map the program headers, which means that some special-case code I
> > > added for SymbianOS can be removed.
> > 
> > Mark,
> > 
> > I've probably missed something subtle here, but these changes are all
> > being made to elfarm-nabi.c, a generic ARM file.  What is it that
> > prevents all these symbian-specific hooks from being called when it's
> > not targeting symbianos?
> 
> It's the usual BFD crock.  elf32-target.h is included twice--once by
> elf32-arm.h, and once, for the Symbian stuff, by elfarm-nabi.c itself.
> 
> (I haven't tried to verify that Mark has done everything correctly,
> but certainly the right framework is there).
> 
> (It would not be unreasonable to create a new file elfarm-symbian.c,
> and make the appropriate functions and data structures in
> elfarm-nabi.c non-static.)

Grr.  I hate the BFD.  In particular I hate the fact that there is much
code in header files, especially elf32-arm.h!  If only I had the time to
restructure it all...

I guess if you are happy with all this, then I am happy :-)

R.

Re: PATCH: Reduce size of SymbianOS DLLs

[Ian Lance Taylor]

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:

> I guess if you are happy with all this, then I am happy :-)

Oh, I don't think anybody is actually happy with it....

I think I first recommended rewriting BFD from scratch in 1993, though
it may have been 1994.

Ian

Re: PATCH: Reduce size of SymbianOS DLLs

[Richard Earnshaw]

On Tue, 2004-11-02 at 15:08, Ian Lance Taylor wrote:
> Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> 
> > I guess if you are happy with all this, then I am happy :-)
> 
> Oh, I don't think anybody is actually happy with it....
> 
> I think I first recommended rewriting BFD from scratch in 1993, though
> it may have been 1994.
> 

:-)

By happy, I meant happy with Mark's patch, not happy with the BFD :-)

R.

Re: PATCH: Reduce size of SymbianOS DLLs

[Daniel Jacobowitz]

On Tue, Nov 02, 2004 at 03:04:07PM +0000, Richard Earnshaw wrote:
> Grr.  I hate the BFD.  In particular I hate the fact that there is much
> code in header files, especially elf32-arm.h!  If only I had the time to
> restructure it all...
> 
> I guess if you are happy with all this, then I am happy :-)

Well now that you mention it...  elf32-arm.h is a header so that it can
be included by elfarm-nabi.c and elfarm-oabi.c.  I haven't seen
indication of the "old, old" ABI being used in a long time.  If I
remember right, you were talking about removing it.

If there's no reason not to do that, we could move all the code from
elf32-arm.h and elfarm-nabi.c to elf32-arm.c (or just move it to
elfarm-nabi.c to avoid disrupting history).  That's real simple.

-- 
Daniel Jacobowitz

Re: PATCH: Reduce size of SymbianOS DLLs

[Richard Earnshaw]

On Tue, 2004-11-02 at 15:17, Daniel Jacobowitz wrote:
> On Tue, Nov 02, 2004 at 03:04:07PM +0000, Richard Earnshaw wrote:
> > Grr.  I hate the BFD.  In particular I hate the fact that there is much
> > code in header files, especially elf32-arm.h!  If only I had the time to
> > restructure it all...
> > 
> > I guess if you are happy with all this, then I am happy :-)
> 
> Well now that you mention it...  elf32-arm.h is a header so that it can
> be included by elfarm-nabi.c and elfarm-oabi.c.  I haven't seen
> indication of the "old, old" ABI being used in a long time.  If I
> remember right, you were talking about removing it.
> 
> If there's no reason not to do that, we could move all the code from
> elf32-arm.h and elfarm-nabi.c to elf32-arm.c (or just move it to
> elfarm-nabi.c to avoid disrupting history).  That's real simple.

I would have thought all the 'interesting' history was in elf32-arm.h,
which we'd loose anyway.  So moving it all to elf32-arm.c would probably
be the 'correct' move for consistency with other architectures.

Are we at the correct point in the release cycle for making this sort of
change?

R.

Re: PATCH: Reduce size of SymbianOS DLLs

[Nick Clifton]

Hi Guys,

>>Well now that you mention it...  elf32-arm.h is a header so that it can
>>be included by elfarm-nabi.c and elfarm-oabi.c.  I haven't seen
>>indication of the "old, old" ABI being used in a long time.  If I
>>remember right, you were talking about removing it.
>>
>>If there's no reason not to do that, we could move all the code from
>>elf32-arm.h and elfarm-nabi.c to elf32-arm.c (or just move it to
>>elfarm-nabi.c to avoid disrupting history).  That's real simple.
> 
> 
> I would have thought all the 'interesting' history was in elf32-arm.h,
> which we'd loose anyway.  So moving it all to elf32-arm.c would probably
> be the 'correct' move for consistency with other architectures.

I would definitely support the idea of obsoleting the "old, old ABI" 
support.  As far as I know there is nobody using it today, but I think 
that we ought to do the proper thing and add the arm-*-oabi target to 
the obsolete configurations section at the start of bfd/config.bfd. 
Then, after the 2.16 release we can remove the old code and merge 
elf32-arm.h and elfarm-nabi.c into elf32-arm.c.

Cheers
   Nick

Re: PATCH: Reduce size of SymbianOS DLLs

[Richard Earnshaw]

On Tue, 2004-11-02 at 15:31, Nick Clifton wrote:
> Hi Guys,
> 
> >>Well now that you mention it...  elf32-arm.h is a header so that it can
> >>be included by elfarm-nabi.c and elfarm-oabi.c.  I haven't seen
> >>indication of the "old, old" ABI being used in a long time.  If I
> >>remember right, you were talking about removing it.
> >>
> >>If there's no reason not to do that, we could move all the code from
> >>elf32-arm.h and elfarm-nabi.c to elf32-arm.c (or just move it to
> >>elfarm-nabi.c to avoid disrupting history).  That's real simple.
> > 
> > 
> > I would have thought all the 'interesting' history was in elf32-arm.h,
> > which we'd loose anyway.  So moving it all to elf32-arm.c would probably
> > be the 'correct' move for consistency with other architectures.
> 
> I would definitely support the idea of obsoleting the "old, old ABI" 
> support.  As far as I know there is nobody using it today, but I think 
> that we ought to do the proper thing and add the arm-*-oabi target to 
> the obsolete configurations section at the start of bfd/config.bfd. 
> Then, after the 2.16 release we can remove the old code and merge 
> elf32-arm.h and elfarm-nabi.c into elf32-arm.c.

If we leave the existing elf32-arm.h around for backwards compatibility
(with elfarm-oabi.c), then we could create a merged elf32-arm.c for
current development work without the need to waste a lot of time testing
that the new changes don't break the old code.

R.

Re: PATCH: Reduce size of SymbianOS DLLs

[Nick Clifton]

Hi Richard,

 > Richard Earnshaw wrote:
 >
> If we leave the existing elf32-arm.h around for backwards compatibility
> (with elfarm-oabi.c), then we could create a merged elf32-arm.c for
> current development work without the need to waste a lot of time testing
> that the new changes don't break the old code.

This is a good idea.  Then when the 2.16 release is out the elf32-arm.h 
and elfarm-oabi.c files could be deleted.

Cheers
   Nick

Re: PATCH: Reduce size of SymbianOS DLLs

[Daniel Jacobowitz]

On Tue, Nov 02, 2004 at 03:32:47PM +0000, Richard Earnshaw wrote:
> On Tue, 2004-11-02 at 15:31, Nick Clifton wrote:
> > Hi Guys,
> > 
> > >>Well now that you mention it...  elf32-arm.h is a header so that it can
> > >>be included by elfarm-nabi.c and elfarm-oabi.c.  I haven't seen
> > >>indication of the "old, old" ABI being used in a long time.  If I
> > >>remember right, you were talking about removing it.
> > >>
> > >>If there's no reason not to do that, we could move all the code from
> > >>elf32-arm.h and elfarm-nabi.c to elf32-arm.c (or just move it to
> > >>elfarm-nabi.c to avoid disrupting history).  That's real simple.
> > > 
> > > 
> > > I would have thought all the 'interesting' history was in elf32-arm.h,
> > > which we'd loose anyway.  So moving it all to elf32-arm.c would probably
> > > be the 'correct' move for consistency with other architectures.
> > 
> > I would definitely support the idea of obsoleting the "old, old ABI" 
> > support.  As far as I know there is nobody using it today, but I think 
> > that we ought to do the proper thing and add the arm-*-oabi target to 
> > the obsolete configurations section at the start of bfd/config.bfd. 
> > Then, after the 2.16 release we can remove the old code and merge 
> > elf32-arm.h and elfarm-nabi.c into elf32-arm.c.
> 
> If we leave the existing elf32-arm.h around for backwards compatibility
> (with elfarm-oabi.c), then we could create a merged elf32-arm.c for
> current development work without the need to waste a lot of time testing
> that the new changes don't break the old code.

How about duplicating elf32-arm.h into both elfarm-oabi.c and
elfarm-nabi.c, and renaming the latter?

Speaking as a packager, I'd be really confused if I forward-ported a
binutils 2.15 patch to 2.16's elf32-arm.h, and discovered it didn't do
anything.

-- 
Daniel Jacobowitz

Re: PATCH: Reduce size of SymbianOS DLLs

[Richard Earnshaw]

On Tue, 2004-11-02 at 15:59, Daniel Jacobowitz wrote:

> How about duplicating elf32-arm.h into both elfarm-oabi.c and
> elfarm-nabi.c, and renaming the latter?
> 
> Speaking as a packager, I'd be really confused if I forward-ported a
> binutils 2.15 patch to 2.16's elf32-arm.h, and discovered it didn't do
> anything.

I've no problem with that.  It means a little more work, but not that
much...

R.

Re: PATCH: Reduce size of SymbianOS DLLs

[Mark Mitchell]

Nick Clifton wrote:

> Hi Richard,
>
> > Richard Earnshaw wrote:
> >
>
>> If we leave the existing elf32-arm.h around for backwards compatibility
>> (with elfarm-oabi.c), then we could create a merged elf32-arm.c for
>> current development work without the need to waste a lot of time testing
>> that the new changes don't break the old code.
>
>
> This is a good idea.  Then when the 2.16 release is out the 
> elf32-arm.h and elfarm-oabi.c files could be deleted.

But, if someone complained and we got convinced that we *did* need the 
old, old ABI, then we might get stuck trying to make changes in two 
places?  I like the obsoletion idea, but I'd be happy to live with 
elf32-arm.h for one more release, before reorganizing.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: PATCH: Reduce size of SymbianOS DLLs

[Daniel Jacobowitz]

On Tue, Nov 02, 2004 at 08:24:45AM -0800, Mark Mitchell wrote:
> Nick Clifton wrote:
> 
> >Hi Richard,
> >
> >> Richard Earnshaw wrote:
> >>
> >
> >>If we leave the existing elf32-arm.h around for backwards compatibility
> >>(with elfarm-oabi.c), then we could create a merged elf32-arm.c for
> >>current development work without the need to waste a lot of time testing
> >>that the new changes don't break the old code.
> >
> >
> >This is a good idea.  Then when the 2.16 release is out the 
> >elf32-arm.h and elfarm-oabi.c files could be deleted.
> 
> But, if someone complained and we got convinced that we *did* need the 
> old, old ABI, then we might get stuck trying to make changes in two 
> places?  I like the obsoletion idea, but I'd be happy to live with 
> elf32-arm.h for one more release, before reorganizing.

I am entirely willing to tell them to go back to 2.15.  This thing is
_dead_.

-- 
Daniel Jacobowitz

Re: PATCH: Reduce size of SymbianOS DLLs

[Mark Mitchell]

Daniel Jacobowitz wrote:

>On Tue, Nov 02, 2004 at 08:24:45AM -0800, Mark Mitchell wrote:
>  
>
>>Nick Clifton wrote:
>>
>>    
>>
>>>Hi Richard,
>>>
>>>      
>>>
>>>>Richard Earnshaw wrote:
>>>>
>>>>        
>>>>
>>>>If we leave the existing elf32-arm.h around for backwards compatibility
>>>>(with elfarm-oabi.c), then we could create a merged elf32-arm.c for
>>>>current development work without the need to waste a lot of time testing
>>>>that the new changes don't break the old code.
>>>>        
>>>>
>>>This is a good idea.  Then when the 2.16 release is out the 
>>>elf32-arm.h and elfarm-oabi.c files could be deleted.
>>>      
>>>
>>But, if someone complained and we got convinced that we *did* need the 
>>old, old ABI, then we might get stuck trying to make changes in two 
>>places?  I like the obsoletion idea, but I'd be happy to live with 
>>elf32-arm.h for one more release, before reorganizing.
>>    
>>
>
>I am entirely willing to tell them to go back to 2.15.  This thing is
>_dead_.
>  
>
OK.  In that case, I'd say we could just remove the code, then.  What's 
the point in pretending we might keep it, if we've already made up our 
minds?

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: PATCH: Reduce size of SymbianOS DLLs

[Mark Mitchell]

Daniel Jacobowitz wrote:

>I am entirely willing to tell them to go back to 2.15.  This thing is
>_dead_.
>  
>
And, now that we've finished this little side-conversation, does anyone 
care to review the patch that started us down this path? :-)

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Obsoleting elfarm-oabi [was Re: PATCH: Reduce size of SymbianOS DLLs]

[Richard Earnshaw]

On Tue, 2004-11-02 at 16:42, Mark Mitchell wrote:
> OK.  In that case, I'd say we could just remove the code, then.  What's 
> the point in pretending we might keep it, if we've already made up our 
> minds?

Let's try and bring this to a rational conclusion.

We have three possible courses of action

1.  Obsolete elfarm-oabi.c, but change nothing for now

2.  Obsolete elfarm-oabi.c and split the code common with the current
ABI into separate files.

3.  Skip obsoleting elfarm-oabi.c and proceed straight to deletion.

I've done some archaeology, and it turns out that the old abi was named
so in February 1999, ie 5+ years ago.  That appears to correspond with
the binutils 2.10 release (we're now at 2.15).  The old ABI was only
ever added as a stop-gap because at the time it was first created ARM
hadn't published an ELF specification for ARM.

Daniel asserts that it isn't really possible to test the oabi code
because the assembler always defaults to the 'new' ABI (even in the oabi
configuration :-) ; this implies that there are almost certainly bugs
(untested code is almost always buggy or bit-rotten in my experience).

A final note is that there is no gcc configuration for the old abi, the
only way it would be even remotely possible to invoke it would be to
pass -Wa,-moabi to every possible invocation of the compiler.   I find
it hard to believe that has been happening for 5 years and yet that
nobody has proposed creating a configuration of gcc that does that by
default.

So my opinion is that we should go straight to option 3.  The 'risk' is
minimal, and if it does materialise we could push back by insisting
somebody else step forward to maintain that specific code if it is
resurrected: once it is separate from the current ARM code that is far
more feasible.

Nick, of course, has a veto; but he doesn't have to use it...

R.

Re: Obsoleting elfarm-oabi [was Re: PATCH: Reduce size of SymbianOS DLLs]

[Nick Clifton]

Hi Richard,

> Let's try and bring this to a rational conclusion.
> 
> We have three possible courses of action
> 
> 1.  Obsolete elfarm-oabi.c, but change nothing for now
> 
> 2.  Obsolete elfarm-oabi.c and split the code common with the current
> ABI into separate files.
> 
> 3.  Skip obsoleting elfarm-oabi.c and proceed straight to deletion.


> So my opinion is that we should go straight to option 3.  The 'risk' is
> minimal, and if it does materialise we could push back by insisting
> somebody else step forward to maintain that specific code if it is
> resurrected: once it is separate from the current ARM code that is far
> more feasible.
> 
> Nick, of course, has a veto; but he doesn't have to use it...

True, but I think that I favour option 2.  We have a mechanism for 
obsoleting targets and I think that we should use it.  I seriously doubt 
if anyone will even notice this target being obsoleted but I do not 
think that we should rush into deleting it just so that we can simplify 
the ARM code today.

Of course if we do go with option 2 we could speak nicely to Daniel and 
maybe get a version 2.16 release branch started sooner rather than 
later, since once that is done we could delete elfarm-oabi.c in the 
mainline sources.  I suspect however that Mark and Code Sourcery might 
prefer us to delay 2.16 until the rest of their arm-symbian patches are 
submitted and applied.  (Assuming that there are more of course).

Cheers
   Nick

PS. Mark: I will look at the patch that started this thread tomorrow if 
Richard does not beat me to it.

Re: Obsoleting elfarm-oabi [was Re: PATCH: Reduce size of SymbianOS DLLs]

[Richard Earnshaw]

On Wed, 2004-11-03 at 15:04, Richard Earnshaw wrote:

> I've done some archaeology, and it turns out that the old abi was named
> so in February 1999, ie 5+ years ago.  That appears to correspond with
> the binutils 2.10 release (we're now at 2.15).  The old ABI was only
> ever added as a stop-gap because at the time it was first created ARM
> hadn't published an ELF specification for ARM.

Some more archaeology.  Following a conversation with Phil Blundel, I
took a look at the old releases.  In binutils 2.9 there was NO support
for ELF on ARM of any kind.  In binutils 2.10 the old ABI was already
that -- old.

So if any release of binutils had the old ABI as its default, it wasn't
an FSF release?

Nick, could this be some GNU PRO legacy?

R.

Re: PATCH: Reduce size of SymbianOS DLLs

[Richard Earnshaw]

On Mon, 2004-11-01 at 21:10, Mark Mitchell wrote:
> The linker believed that SymbianOS BPABI DLLs were demand-paged, which
> meant that it wanted to align segments on page-size boundaries.
> However, all BPABI DLLs are post-processed before becoming something
> that can actually be executed, so this is just wasted space in the
> file.  I realized that when D_PAGED is clear, the linker will not try
> to map the program headers, which means that some special-case code I
> added for SymbianOS can be removed.
> 
> OK?

OK.

R.

Re: Obsoleting elfarm-oabi [was Re: PATCH: Reduce size of SymbianOS DLLs]

[Nick Clifton]

Hi Richard,

> Some more archaeology.  Following a conversation with Phil Blundel, I
> took a look at the old releases.  In binutils 2.9 there was NO support
> for ELF on ARM of any kind.  In binutils 2.10 the old ABI was already
> that -- old.
> 
> So if any release of binutils had the old ABI as its default, it wasn't
> an FSF release?
> 
> Nick, could this be some GNU PRO legacy?

Thinking about it, yes I think that you are right.  It must have been a 
release from back in the Cygnus days that happened between 2.9 and 2.10.

Given that there never was an official FSF release that supported this 
oabi I can see no reason to retain the code in the binutils sources.  If 
there are any oabi users out there they can complain to Red Hat and get 
support there.

So - please do go ahead and delete the oabi code.

Cheers
   Nick