Subject:
|
Re: Possible bug with bss allocation
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 22 Jul 2000 20:49:42 GMT
|
Viewed:
|
1295 times
|
| |
|
|
> > The common section is aligned to 16 bytes by ld. This is unknown to
> > the tools generating the final .lx files.
> >
> > The fix is to force the alignment of the .bss section to 2, with this
> > ld will generate files that work with the current tools. I changed
> > genlds.c in CVS at sourceforge.net to output the correct linker script
> > for this.
> >
> > If you are using this, please make shure genlds gets rebuild, issue a
> > make realclean in your legOS directory.
>
>
> Thanks for the fix, it works great.
I have a proposal to the legOS developers:
The current tool chain to generate executables for legOS is a little off:
We generate coff-h8300 from .c or .S sources, next ld generates symbolsrec
relocated files from that. This step is done twice for .lx executables, to
later find the places where relocation occurred, and the .lx executable is
generated.
I would propose a change to this tool chain, to reduce possible bugs like
the one above (the actual bug is that makelx does not care about the start
of the .data and .bss sections, but assumes they directly follow the previous
section).
We should generate coff-h8300 from .c and .S like before. After that we
should use ld to generate coff-h8300 relocatable files from that. Last
makelx would relocate that file, and generate the .lx executable.
Steps involved from make would look like this:
h8300-hitachi-hms-gcc -O2 -fno-builtin -fomit-frame-pointer -Wall \
-I/reset/u1/ecd/lego/mindstorms/legos/cvs/legOS/include \
-I/reset/u1/ecd/lego/mindstorms/legos/cvs/legOS/include/lnp \
-I. -I../boot/ -c test.c -o test.o
h8300-hitachi-hms-ld -T ../boot/legOS.lds -Ttext 0xb000 -r \
-L/reset/u1/ecd/lego/mindstorms/legos/cvs/legOS/lib \
test.o -lc -lmint -lfloat -lc++ -o test.r
/reset/u1/ecd/lego/mindstorms/legos/cvs/legOS/util/makelx test.r test.lx
With this approach, makelx has full section, symbol and relocation info
in the .r file, and can do a much better job moving sections around (in
case ld introduces extra alignment and such).
Also you get the chance to disassemble the binary, look at the relocs or
symbols with h8300-hitachi-hms-objdump, a lot better then when looking
at srecs with objdump.
If you need the srecs for anything, you can always use
ld -oformat symbolsrec to relocate the image and generate srecs.
If noone objects, I would implement this. The Makefile changes are trivial,
only major change is to makelx, which would read coff files. I have done
these things before, so this would not be too hard.
Eddie C. Dost
ecd@skynet.be
|
|
Message has 1 Reply:
 | | Re: Possible bug with bss allocation
|
| "Eddie C. Dost" <ecd@skynet.be> wrote in message news:200007222049.WA...set.net... (...) trivial, (...) In my opinion this is a great idea! :-) Please do the implementation! It also could be very usefull to have some docs / makefile options to make (...) (24 years ago, 23-Jul-00, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
8 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
