New targets to Binutils for H8 series
Wed Jan 22 12:35:00 GMT 2003
> Hi Venky,
> > I think it would be a good idea to add a target, say
> > -msim, so that the code is generated for simulated target only.
> Generally speaking this is a bad idea. Simulators ought to be able to
> simulate code compiled for real targets. You should not have to
> compile a program for a "simulator-only" target.
I do tend to agree with you on that. It may not be bad but yeah, its
ugly. Anyways, I was not trying to change code generation, only adding
an option for adding some extra startup code.
> > In the context, I was actually trying to include commandline support
> > to the simulator and so would have to setup the stack with the
> > commandline arguments in crt0.S. I didn't think it would be a good
> > idea to add the code to the default implementation, by adding the
> > target, we could write any simulator specific code inside a #ifdef
> > __SIMULATOR__ kind of structure, similar to the ARM implementation.
> Are you saying that the default target execution environment for H8300
> binaries does not have any way of obtaining its command line ? So you
> want to invent one that will work with the simulator ? If so, then I
> can understand your desire to have a "-msim" switch, but I still think
> that it is a bad idea. Instead I would suggest that you do something
> similar to the mechanism used in newlib for the ARM.
> In the file newlib/configure.host, for the h8300 entry, add an new
> define, eg -DSIMULATOR_ARGV_SUPPORT and then test for this in crt0.S.
> You still end up with a customised-for-the-simulator crt0.o file, but
> these do tend to be execution environment specific, and normally a
> user would use a spec file to select the correct crt0.o for their
> execution environment.
Well, that is one of the ways, and in fact, I would like to adopt this
method. This approach is actually similar to the -msim option above,
just that this would result in a change in newlib, whereas that would
have been global. Thank you for this suggestion.
H8300 has some other problems, in ARM there seems to be 0x0000 - 0x8000
memory that is free, so they store the commandline string at 0xf00L. In
the H8300 linker script, it is a little ambiguous.
/* 0xc4 is a magic entry. We should have the linker just
skip over it one day... */
vectors : o = 0x0000, l = 0xc4
magicvectors : o = 0xc4, l = 0x3c
ram : o = 0x0100, l = 0xfdfc
/* The stack starts at the top of main ram. */
topram : o = 0xfefc, l = 0x4
/* At the very top of the address space is the 8-bit area. */
eight : o = 0xff00, l = 0x100
Now, there is this 8-bit area, from 0xff00, having 256 bytes, I could save
the commandline string here and set the pointers on the stack in crt0.S.
But this would render the 8-bit area, fully occupied leaving no free space
(I guess, this area is free space). If some new requirement for free space
comes, then, it would be a problem :-(. And if someone changes the linker
script to enable more simulator memory, then, a change will also be required
in crt0.S. But I guess, this is the best possible strategy available to us.
A question about calling conventions, the calling conventions for variable
arguments is not clear. For a commandline like,
a.out arg1 arg2 arg3 ...
Register 0 should have 4, the first argument to main.
Register 1 should contain a pointer to 'a' in the commandline string.
Should Register 2 have pointer to arg1?
What should the stack be?
Should it be pointers to :
<--- Top of the stack
arg3 | Decreasing Address
<--- Bottom of the stack
arg2 | Decreasing Address
. | Decreasing Address
I am pretty confused about this, could someone elaborate this
point. Any useful hints, I have seen the Hitachi calling
conventions on their website, there is no mention of calling
conventions for variable arguments.
Thanks and Regards,
More information about the Binutils