Mark Wielaard <mjw(a)redhat.com> writes:
On Thu, Aug 02, 2012 at 01:43:10AM +0200, Petr Machata wrote:
> these two patches implement support for 64-bit symbol table in .a
> archives. As of recently, binutils' ar produces such archives on s390x
> (regardless of actual archive size). This appears to be the same as
> "/", except all fields are 64-bit.
Just a quick partial review, with some pedantic comments. Have to read
up on ar archives. But it looks correct to me. Are the magic entries
("/SYM64/") described somewhere in a specification document or is this
GNU specific?
I went with the assumption that it's just like "/", except 64-bit where
"/" is 32-bit. I found something now, page 97:
http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-00...
This is Irix documentation, 64-bit Irix is where this format comes from.
> - Copyright (C) 1998, 1999, 2000, 2002, 2005 Red Hat, Inc.
> + Copyright (C) 1998-2012 Red Hat, Inc.
This should be 1998-2000, 2002, 2005, 2012. Only the first is a full
range. Similarly in some other places. (Yes, I did ask a lawyer.)
I'll correct this. I recalled something with coalescing individual
years into ranges, but wasn't actually sure what the rule was.
> - /* Now test whether this is the index. It is denoted by
the
> - name being "/ ".
> + bool index64_p;
> + /* Now test whether this is the index. If the name is "/", this
> + is 32-bit index, if it's "/SYM64/", it's 64-bit index.
> +
> XXX This is not entirely true. There are some more forms.
> Which of them shall we handle? */
Is this still true? Which other forms are there?
I don't know. In Linkers & Loaders, Levine mentions several different
formats for "/" and one for "__.SYMDEF". The latter was reportedly
used
in original BSD and in a.out archives. I'm not sure it's relevant
anymore.
It would be more consistent to cal this run-test-archive64.sh.
Will fix. (Not that there is much consistency otherwise ;) )
> +
> +testfiles archive64.a
Please document here how archive64.a was created.
Humm, I took a bunch of elfutils objects, but now that I think of it, we
would have to ship the exact same source that led to their creation.
Maybe instead I'll invent a couple trivial one-liners that can easily be
pasted to run-test-archive64.sh. Would that work?
Thank you,
PM