Subject:
|
Possible bug with bss allocation
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 22 Jul 2000 03:53:51 GMT
|
Viewed:
|
1376 times
|
| |
|
|
I was having some random hangs with a legOS program. If I added a
little code or subtracted a little, everything started working again.
I've isolated it to a problem whereby writing a zero to the last byte of
bss data will hang the RCX. This only happens when the length of the
.text segment (and presumably .data and .bss segments) are just right.
In my testing, I always had a multiple of 16 bytes of .bss data and no
.data segment. If the .text segment's length mod 16 was equal to 4,
then I got the hang. I'm guessing that some important housekeeping
structure is overlapped with the end of the .bss segment and if the
alignment is just write, then zeroing out that last byte of .bss data
has dire consequences. This seemed to happen regardless to the
magnitued of the .bss and .text sizes. The example below is pretty
minimal, but I also saw it happening with a 4K text segment and 1K of
bss. Here's a test program:
------
#include <conio.h>
// comment out the following line to check the normal size
#define NON_PADDED_TEXT_SIZE 0x22
#define BSS_SIZE 0x10
char bss_data[BSS_SIZE];
#ifdef NON_PADDED_TEXT_SIZE
// pad the text segment
#define DESIRED_TEXT_SIZE 0x34
const char textpad[DESIRED_TEXT_SIZE - NON_PADDED_TEXT_SIZE] = {1};
#endif
int main(int argc, char **argv)
{
cputw(1);
msleep(100);
bss_data[BSS_SIZE - 1] = 0;
cputw(2);
return 0;
}
------
The code is a little strange because I wanted to be able to add/delete
code but still force the .text segment to a certain length. There's
probably a cool way to do this with linker directives, but I took the
brute force approach.
Commment out the #define NON_PADDED_TEXT_SIZE line, then build the
program. Note the .text segment size (I just hexdumped the .lx file and
looked at bytes 10 and 11). Then put that value in for
NON_PADDED_TEXT_SIZE and uncomment the line and rebuild. You should now
have a program with text size of DESIRED_TEXT_SIZE. If you add lots of
code, just make sure DESIRED_TEXT_SIZE is at least one byte larger than
the actual non-padded size.
When I run this program the RCX locks up with "1" displayed on the LCD.
If I tweak the text size a bit, then program runs normally ("2" is
displayed and RCX is still functional). I think some other text lengths
(other than 4 mod 16) cause more subtle problems, such as not being able
to come up out of power-up reliably.
I'm not up to speed enough on legOS to sort this out any further -
perhaps someone with more experience with how programs are
stored/executed could shed some light on what is happening.
Until then, if you seem to experience random crashes and simply adding a
line or string changes this behavior, then you may be running into this
bug. A decent workaround should be to pad the end of your bss data. 2
bytes is probably enough, 16 should be really safe.
Dave Baum
--
reply to: dbaum at enteract dot com
|
|
Message has 1 Reply:
 | | Re: Possible bug with bss allocation
|
| (...) 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 (...) (24 years ago, 22-Jul-00, to lugnet.robotics.rcx.legos)
|
8 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
