Re: [microblaze-uclinux] abi change

["Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>]

On Mon, Jun 15, 2009 at 08:49:18AM +1000, John Williams wrote:
> Hi Edgar,
> 
> On Thu, Jun 11, 2009 at 9:00 AM, Edgar E.
> Iglesias<edgar.iglesias@xxxxxxxxx> wrote:
> > Since the ABI was recently changed for stat, I was curios if there
> > is a way to tell executable apart, maybe by some ELF flag or
> > something?
> 
> We've not implemented anything like that, and to be honest I don't
> know enough about the ELF format to say how feasible it would be to
> automatically tag ELF files in that way.
> 
> And, there is the question, what can you do with it?  If the ELF
> loader detects an app built against old stat.h, refuse to load it?
> We've basically worked on the premise that the upstream 2.6.30 and
> beyond is a new architecture port, and taken a clean slate regarding
> the ABI.  We expect the people will rebuild their apps and libs when
> they make the transition, rather than looking for any sort of binary
> compatability.

Hi John,

Makes sense. My main thought was to automatically support both ABI's
in QEMU. Also if you suspect that people will share binaries often and
run into runtime errors, it might be nicer to get an explicit
incompatibility message than random segfaults.

IIRC I've seen the ELF headers Flag field beeing used to signal
ABI differences.

> If you have any ideas on how this might be achieved and why it would
> be useful, please let us know!
> 
> > Also, is there someway to tell from an ELF executable what parts
> > of the microblaze ISA it needs (barrel, pcmp etc) by lookin at
> > the ELF file?
> 
> Well you could do an objdump -S and grep for the relevant opcodes, but
> I suspect you are meaning a run time approach on the microblaze?
> 
> Otherwise it may be possible to add a debug / info section to the ELF
> files and put some representation of the ISA-specific CFLAGS in there
> - I'm not an ELF/binutils expert so I'm not sure the best way that
> would be achieved.
> 
> This might be helpful because the ELF loader could potentially check
> these flags and cross-reference against /proc/cpuinfo, torefuse to
> load a binary that requires more CPU features than are currently
> configured.  Maybe better than just erroring out with an invalid
> opcode exception.

Yes, I guess it's slightly better because you know your apps will run
at loadtime without needing to verify all possible code paths. But the
way things work now, at least you get explicit messages when things go
wrong (illegal insn).

Cheers
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/