From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-31 11:09:56
On Wed, Mar 30, 2005 at 11:06:27PM +0200, Ullrich von Bassewitz wrote:
>
> On Wed, Mar 30, 2005 at 09:41:22PM +0200, Gabor Lenart wrote:
> > No, as I've said I would introduce a new mode bit to mean "old CPU type bit
> > (6502/65816) is obsoleted you should ignore it and check with the new
> > method instead". If this bit IS set, you can stop now and refuse further
> > work with that object. However you're right it's a "bit" messy solution.
>
> Ok. But once I would like to check if the module is compiled for the 65C02, I
> have a problem.
You have a problem NOW as well, since the current format simply can't
tell you if object was compiled for 6502 or 65C02, right? So there SHOULD BE
some modifications in the format done! Because current format can only
specify 6502/65816 so you can't check 65C02 for example.
> > So I see it's absolutly better to create a bit complicated scheme (like my
> > idea, of course better solution can be found, probably) than to have
> > several absolutly different home grown (I mean every developer would have
> > totally different) formats.
>
> Another option would be to look for an executable file format that has the
> features you want. It's a common mistake to aim too high, and I would hate to
> see André fall into this trap.
Yes, but modern systems do use real-time linking (rtld) when 'execute'
something. Also an object format is used to link with other objects at
some point: So the purpose is the SAME, you should not separate these
problems at all. Both of 'executable' and 'object' format is used to
link something with other objects/libraries and even with the kernel
(like kernel modules in case of Linux for example). No major difference.
So there is no need to separate these purporses of object files.
> > Anyway please warn me to stop flaming if you find my mails meaningless or
> > desctructive :) or something.
>
> No problem with me:-) But I think, all is said, and it's Andrés decision now.
OK :)
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.