The message below didn't appear in the Archives after 48 hours or so maybe due to spam filtering, so I am re-sending after joining the list to see if that works.
Chris On Sun, 12 Oct 2025 23:04:03 +0800 Chris Billington <[email protected]> wrote: > Dear dmidecode developers, > > I am an OpenBSD user and have been using the OpenBSD port for > dmidecode-3.6. On OpenBSD, with no sysfs or easy userspace access to > EFI table listings, dmidecode falls back to scanning /dev/mem at the > legacy bios address range from 0xF0000-0xFFFFF. > On many modern UEFI machines, there is no SMBIOS information in this > range, so the entry point and table information cannot be found. This > is the case on two of three of my own amd64 machines. > > However, the OpenBSD EFI bootloader does scan EFI tables and the > SMBIOS entry point, if found, appears in the system message buffer on > boot, for example: > ... > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa4df8000 (36 entries) > ... > > I found that by hard-coding the memory-scan base address, dmidecode > works normally. I then created a patch to add a command-line option > -m/--mem-base <addr> to pass an arbitrary address to the memory-scan > function. This may also be useful as an advanced option on > machines that have incorrect info in efi tables. Without the -m > option, the code behaves as before. > > While making the patch I found that some of the short-option codes > (-S, -O...) in dmiopt.c were not in the dmidecode(8) manpage or the > help text, so added those into the patch. > > Another suggested patch is to make FLAG_NO_SYSFS the default on > OpenBSD (it may also be useful to do this on other BSDs). > > Git HEAD as of today with the patch builds and works correctly on both > my legacy-free machines and also on the third machine with the legacy > bios information. > > Compilation warnings > > OpenBSD uses clang as default compiler. Both before and after the > patch, it emits -Wcast-align warnings for each use of the macros WORD, > DWORD and QWORD defined in type.h, about 300 in total. > > Example: > > dmidecode.c:612:26: warning: cast from 'const u8 *' (aka 'const > unsigned char *') to 'const u16 *' (aka 'const unsigned short *') > increases required alignment from 1 to 2 [-Wcast-align] > pr_list_item("0x%04X", WORD(p + sizeof(u16) * i)); > ^~~~~~~~~~~~~~~~~~~~~~~~~ ./types.h:31:24: note: expanded from macro > 'WORD' > #define WORD(x) (u16)(*(const u16 *)(x)) > ^~~~~~~~~~~~~~~~ > > Compilation succeeds, because the x86 platform is tolerant of such > alignment issues. However, other platforms that need strict alignment > may not build. (The port is amd64/i386 only on OpenBSD, however). > > I made a patch for types.h that avoids these cast-alignment warnings > by using memcpy() to ensure alignment on architectures that allow > unaligned reads, like x86. > > I attach two git diffs against HEAD (12 Oct 25/ > fa268715c0d7d8895842c6f9b92bcc1a17790000): > option-m-docs.diff (-m and dmidecode.8) > types-h.diff (-Wcast-align) > > Tested on amd64 with clang16 and gcc 11.2 > > Would you have any interest in adding these patches to your codebase, > rather than OpenBSD making local changes to their port? They could be > useful to general users on other platforms. I isolated the changes to > types.h so they can be tested separately. If you would prefer to > receive patches in a different format please let me know. > > -- > Chris Billington <[email protected]>
option-m-docs.diff
Description: Binary data
types.h.diff
Description: Binary data
