I received this bug report this morning from a Digital Unix user testing
R3.14.0beta2. I've replied to him about the bug tracker stuff, but I'll
leave the RISC_pad issue to Jeff and/or Marty to fix. I'm not convinced
that we should be using dbr_long_t but it might be right.
- Andrew
--
"Life is what happens while you're busy making other plans." - John Lennon
--- Begin Message ---
Hi Andrew,
Sorry if you aren't a good person for this but I saw your address on the bug reporting page and
didn't want to bother tech-talk with this.
Firstly, I tried to register with the bug reporting page (as "pct") but I got a database error. It
seems to have created the id but trying the process again caused a new error along the lines that
the ID already exists. I suppose it still may send a password but it looked broken. It's only been
30 mins.
Secondly, I've been playing with EPICS 3.14.0 beta 2 for the last couple of month and have been
compiling the base under Linux and then under Digital Unix 4.0D. In the latter, I found one "bug"
and have made a fix for it but was wondering what to do with any bug report and suggested fix for
possible inclusion in any future updates. So if you have any instructions, that would be good.
I'll outline the bug and fix below in case you know what to do with it, or otherwise simply reply
with suggestions and I'll follow it up.
So to the problem. It is a structure alignment problem that is only an issue with machines with 64
bit longs that need to be on 8 byte boundaries (such as the alpha). The dbr_time_double structure
in src/db/db_access.c and src/ca/db_access.h were different sizes and had different alignment for
some fields. These structures seem to be typecast between each other. So:
In src/db/db_access.c the dbr_time_double structure has RISC_pad as a long. So the structure is:
Byte offset Field Type Size (bytes)
0 status short 2
2 severity short 2
4 stamp (2 * epicsUInt32) 2*4
12-15 EMPTY - pad for boundary alignment
16 RISC_pad long 8
24 value double 8
In src/ca/db_access.h the dbr_time_double structure has RISC_pad as a dbr_long_t - a 32 bit integer.
So the structure is:
Byte offset Field Type Size (bytes)
0 status dbr_short_t 2
2 severity dbr_short_t 2
4 stamp (2 * epicsUInt32) 2*4
12 RISC_pad dbr_long_t 4
16 value dbr_double_t 8
I suspect there are other db structures that will have the same problem but I haven't evaluated them
yet.
My fix was to change RISC_pad in src/db/db_access.c from a "long" to an "int". I don't know what
impact this may have on other architectures but this fix is fine for both the alpha and under Linux.
Thanks.
Paul (Tyler)
--- End Message ---
- Replies:
- Re: RISC_pad in dbr_time_double Marty Kraimer
- RE: RISC_pad in dbr_time_double Jeff Hill
- Navigate by Date:
- Prev:
Re: POSIX recursive mutex Marty Kraimer
- Next:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
- Navigate by Thread:
- Prev:
epicsMutexLockWithTimeout - where is it called Jeff Hill
- Next:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
|