Hmm. that's a good point. It does look like a repeated structure. I will look into it.
-Matt On Mon, Jan 27, 2020 at 4:15 PM Romick <[email protected]> wrote: > I was probably lucky :) Of course, I could be wrong, but it seems to me > that these pieces are not "fields" of the same structure, these are fields > that belong to two records in the file. Is the order of these records > guaranteed? > > I mean, it’s possible if I rebuild the world now, the linker will arrange > these records in a different order and everything will be fine, or maybe > not :) > > On Mon, Jan 27, 2020 at 03:56:25PM -0800, Matthew Dillon wrote: > > That's ... weird. the 'zero' and the 'version' fields are transposed. > Are you > > compiling in any special way? I've tested -release and -master on a > bunch of > > boxes and they all have the version in the right spot. > > > > -Matt > > > > On Mon, Jan 27, 2020 at 1:45 PM Romick <[email protected]> > wrote: > > > > Hello, > > It seems that dsynth defines the system version based on the > .note.tag(s) > > in > > /bin/sh and a necessary condition is that these entries follow in a > > certain order. On my system this is not so :) > > > > ========== > > rabbit@fly ~% readelf -x .note.tag /bin/sh > > > > Hex dump of section '.note.tag': > > 0x00400218 0a000000 04000000 20000000 44726167 ........ ...Drag > > 0x00400228 6f6e466c 79000000 00000000 0a000000 onFly........... > > 0x00400238 04000000 01000000 44726167 6f6e466c ........DragonFl > > 0x00400248 79000000 e5a30700 y....... > > > > rabbit@fly ~% > > ========== > > > > === /usr/src/usr.bin/dsynth/config.c === > > struct NoteTag { > > Elf_Note note; > > char osname1[12]; > > int version; /* e.g. 500702 -> 5.7 */ > > int x1; > > int x2; > > int x3; > > char osname2[12]; > > int zero; > > }; > > ======================================== > > > > -- > > with best regards, > > Yellow Rabbit @[email protected] > > DragonFly 5.7-DEVELOPMENT x86_64 > > > > -- > with best regards, > Yellow Rabbit @[email protected] > DragonFly 5.7-DEVELOPMENT x86_64 >
