binutils 2.17 branch

binutils 2.17 branch

[Daniel Jacobowitz]

Hi folks,

It's about time for the next release of binutils.  Are there any
upcoming projects that you expect to be submitted soon that 2.17
should wait for - or, alternatively, that should wait until after
2.17 so that they have more time to settle?  Any recent changes
that need a little longer?

The only thing I've got my eye on at the moment is Alan's recent
--as-needed fixes; experience suggests it will take a little
while for that to settle down.

-- 
Daniel Jacobowitz
CodeSourcery

Re: binutils 2.17 branch

[Alan Modra]

On Thu, Mar 16, 2006 at 10:04:06PM -0500, Daniel Jacobowitz wrote:
> The only thing I've got my eye on at the moment is Alan's recent
> --as-needed fixes; experience suggests it will take a little
> while for that to settle down.

Yes, that Alan Modra bloke can be unreliable. :)

Seriously, it's still somewhat of a hack.  The fact that we throw away
syms added for an unneeded lib means I'm relying on nothing
(eg. backend add_symbol_hook) keeping pointers into the symbol hash
table apart from the ones I already handle (undefs, sym_hashes).
I also don't like doubling the symbol table memory usage.

The technically better approach, of scanning as-needed lib syms to
determine whether to load the lib has its own set of problems.  You need
to fairly carefully duplicate existing code behaviour in deciding
whether a definition will satisfy a reference.  Symbol versioning
complicates this process.  Also, you'd need to modify the backend
add_symbol_hook functions to only discard symbols during the scan.
I felt that getting this approach right would take longer than
checkpointing the hash table..

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: binutils 2.17 branch

[Daniel Jacobowitz]

On Fri, Mar 17, 2006 at 03:47:04PM +1030, Alan Modra wrote:
> Seriously, it's still somewhat of a hack.  The fact that we throw away
> syms added for an unneeded lib means I'm relying on nothing
> (eg. backend add_symbol_hook) keeping pointers into the symbol hash
> table apart from the ones I already handle (undefs, sym_hashes).

Yeah, I noticed that.  I see why you did it this way, though, and I
think it will work better now than before - but I'd like it to have
a bit of testing before it goes into a release; Debian folks have
been complaining about bad --as-needed behavior since they discovered
it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: binutils 2.17 branch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

On Fri, Mar 17, 2006 at 10:07:03AM -0500, Daniel Jacobowitz wrote:
> On Fri, Mar 17, 2006 at 03:47:04PM +1030, Alan Modra wrote:
> > Seriously, it's still somewhat of a hack.  The fact that we throw away
> > syms added for an unneeded lib means I'm relying on nothing
> > (eg. backend add_symbol_hook) keeping pointers into the symbol hash
> > table apart from the ones I already handle (undefs, sym_hashes).
> 
> Yeah, I noticed that.  I see why you did it this way, though, and I
> think it will work better now than before - but I'd like it to have
> a bit of testing before it goes into a release; Debian folks have
> been complaining about bad --as-needed behavior since they discovered
> it.

I'll provide my --as-needed testing results with 5000+ packages from
ALT Sisyphus in a few days.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: binutils 2.17 branch

[Martin Michlmayr]

* Dmitry V. Levin <ldv@altlinux.org> [2006-03-17 18:40]:
> > Yeah, I noticed that.  I see why you did it this way, though, and I
> > think it will work better now than before - but I'd like it to have
> > a bit of testing before it goes into a release; Debian folks have
> > been complaining about bad --as-needed behavior since they discovered
> > it.
> 
> I'll provide my --as-needed testing results with 5000+ packages from
> ALT Sisyphus in a few days.

Did you ever post these results?  I cannot remember seeing anything.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: binutils 2.17 branch

[Martin Michlmayr]

* Daniel Jacobowitz <drow@false.org> [2006-03-16 22:04]:
> It's about time for the next release of binutils.  Are there any
> upcoming projects that you expect to be submitted soon that 2.17
> should wait for - or, alternatively, that should wait until after
> 2.17 so that they have more time to settle?  Any recent changes that
> need a little longer?

What's the status of this?

I've recently compiled the whole Debian archive with GCC 4.1 on MIPS
and AMD64 and I'd like to do the same with binutils when 2.17 has its
own branch.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: binutils 2.17 branch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Sat, Apr 08, 2006 at 09:09:21PM +0200, Martin Michlmayr wrote:
> * Dmitry V. Levin <ldv@altlinux.org> [2006-03-17 18:40]:
> > > Yeah, I noticed that.  I see why you did it this way, though, and I
> > > think it will work better now than before - but I'd like it to have
> > > a bit of testing before it goes into a release; Debian folks have
> > > been complaining about bad --as-needed behavior since they discovered
> > > it.
> > 
> > I'll provide my --as-needed testing results with 5000+ packages from
> > ALT Sisyphus in a few days.
> 
> Did you ever post these results?  I cannot remember seeing anything.

I posted here 3 weeks ago about fixed binutils:
"No assertion fails, no internal errors, no segfaults anymore."

Of course a lot of binaries don't link when --as-needed is specified
due to incorrect usage: libraries specified before objects, objects linked
with underlinked libraries, etc.  These bugs are not related to binutils,
but since we enabled --as-needed by default in Sisyphus, we have to fix
such bugs.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: binutils 2.17 branch

[Daniel Jacobowitz]

On Sat, Apr 08, 2006 at 09:11:38PM +0200, Martin Michlmayr wrote:
> * Daniel Jacobowitz <drow@false.org> [2006-03-16 22:04]:
> > It's about time for the next release of binutils.  Are there any
> > upcoming projects that you expect to be submitted soon that 2.17
> > should wait for - or, alternatively, that should wait until after
> > 2.17 so that they have more time to settle?  Any recent changes that
> > need a little longer?
> 
> What's the status of this?
> 
> I've recently compiled the whole Debian archive with GCC 4.1 on MIPS
> and AMD64 and I'd like to do the same with binutils when 2.17 has its
> own branch.

I was going to do it some days ago, but I didn't have time, as you all
can doubtless tell.

Binutils has seemed fairly stable over the last few weeks.  Unless
anyone hollers, I will plan to create the branch this weekend.  The
pre-release and release process usually takes us about a month.

-- 
Daniel Jacobowitz
CodeSourcery