- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Utility to change "image file identification"?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-13-2012 06:26 AM
07-13-2012 06:26 AM
Re: Utility to change "image file identification"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-13-2012 12:21 PM
07-13-2012 12:21 PM
Re: Utility to change "image file identification"?
Harmut,
I did realize that the linker's IDENTIFICATION option string can be longer than 7 characters not including the
terminating null byte. So I reworked the code. The new code has been tested using binutils' readelf and is available at the same URL. I have set the ID string buffer limit to 80 inside the code. I hope it is large enough.
I have been misled by your imgid run on Alpha.
Philippe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-16-2012 09:38 AM
07-16-2012 09:38 AM
Re: Utility to change "image file identification"?
I still think Philippe's code won't do the right thing if you expand an image ident such that the .note section grows past a page boundary. If you have to bump other sections down inside the file, you have LOTS of work to do to recompute all the section offsets in the header table.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-17-2012 05:37 AM
07-17-2012 05:37 AM
Re: Utility to change "image file identification"?
John,
Do not think ! Send me an actual VMS image where the code I post does not do the trick and I'll rework upon it. On Itanium, I use both analyze/image and binutils' readelf to control. On Alpha, I only know of analyze/image.
Regards,
Philippe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-17-2012 11:23 AM
07-17-2012 11:23 AM
Re: Utility to change "image file identification"?
John,
As you can read from this binutils's readelf run, the IA64 VMS Linker aligns the .note section on a disk block boundary and the .note length does not exceed a disk block.
$ readelf -a Rudy.EXE
ELF Header:
Magic: 7f 45 4c 46 02 01 01 0d 02 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: VMS - OpenVMS
ABI Version: 2
Type: EXEC (Executable file)
Machine: Intel IA-64
Version: 0x1
Entry point address: 0x501c8
Start of program headers: 72 (bytes into file)
Start of section headers: 11784 (bytes into file)
Flags: 0x1000014, 64-bit, vms_linkages
Size of this header: 72 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 6
Size of section headers: 64 (bytes)
Number of section headers: 9
Section header string table index: 1
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .shstrtab STRTAB 0000000000000000 00002c08
0000000000000056 0000000000000000 0 0 0
[ 2] .strtab STRTAB 0000000000000000 00002a08
0000000000000001 0000000000000000 0 0 0
[ 3] .debug_line VMS_TRACE 0000000000000000 00001e00
000000000000020f 0000000000000000 0 0 1
[ 4] .trace_abbrev VMS_TRACE 0000000000000000 00002200
000000000000001e 0000000000000000 0 0 1
[ 5] .trace_info VMS_TRACE 0000000000000000 00002400
000000000000006c 0000000000000000 0 0 1
[ 6] .trace_aranges VMS_TRACE 0000000000000000 00002600
0000000000000030 0000000000000000 0 0 1
[ 7] .note NOTE 0000000000000000 00002800
0000000000000188 0000000000000000 0 0 0
[ 8] .dynstr STRTAB 0000000000000000 00001750
000000000000000a 0000000000000000 A 0 0 0
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000010000 0x0000000000000000
0x0000000000000000 0x0000000000001230 RW 10
LOAD 0x0000000000000200 0x0000000000020000 0x0000000000000000
0x0000000000000c90 0x0000000000000c90 R E 10
LOAD 0x0000000000001000 0x0000000000030000 0x0000000000000000
0x00000000000000b0 0x00000000000000b0 R 10
LOAD 0x0000000000001200 0x0000000000040000 0x0000000000000000
0x0000000000000100 0x0000000000000100 R 8
LOAD 0x0000000000001400 0x0000000000050000 0x0000000000000000
0x00000000000001f8 0x00000000000001f8 R 10
DYNAMIC 0x0000000000001600 0x0000000080000000 0x0000000000000000
0x0000000000000668 0x0000000000000668 R 200
Section to Segment mapping:
Segment Sections...
00
01
02
03
04
05
Dynamic section at offset 0x1600 contains 21 entries:
Tag Type Name/Value
0x0000000060000019 (VMS_IDENT) 0x12c457f1337f3
0x0000000060000035 (VMS_LINKTIME) 2012-07-14T19:26:47
0x000000006000004d (VMS_PLTGOT_SEG) 0x4
0x000000006000004b (VMS_PLTGOT_OFFSET) 0x200000
0x000000006000002f (VMS_UNWINDSZ) 0x60
0x0000000060000031 (VMS_UNWIND_CODSEG) 0x1
0x0000000060000033 (VMS_UNWIND_INFOSEG) 0x3
0x000000006000003d (VMS_UNWIND_OFFSET) 0x0
0x000000006000003f (VMS_UNWIND_SEG) 0x3
0x000000006000004f (VMS_FPMODE) 0x9800000
0x0000000060000041 (VMS_STRTAB_OFFSET) 0x150
0x000000000000000a (STRSZ) 10 (bytes)
0x000000006000001d (VMS_NEEDED_IDENT) 0x2000100000001
0x0000000000000001 (NEEDED) Shared library: [DECC$SHR]
0x0000000060000025 (VMS_FIXUP_NEEDED) 0x0
0x0000000060000023 (VMS_FIXUP_RELA_CNT) 0x13
0x0000000060000049 (VMS_FIXUP_RELA_OFF) 0x160
0x0000000060000015 (VMS_LNKFLAGS) 0x4a0 IMGSTA MAIN TBK_IN_IMG
0x000000006000001f (VMS_IMG_RELA_CNT) 0x11
0x0000000060000045 (VMS_IMG_RELA_OFF) 0x3c0
0x0000000000000000 (NULL) 0xdead
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.
Notes at offset 0x00002800 with length 0x00000188:
Owner Data size Description
IPF/VMS 0x00000005 NT_VMS_IMGNAM (image name)
Image name: RUDY
IPF/VMS 0x00000005 NT_VMS_GSTNAM (sym table name)
Global symbol table name: Rudy
IPF/VMS 0x00000010 NT_VMS_IMGID (image id)
Image id: 123456789012345
IPF/VMS 0x00000020 NT_VMS_IMGBID (build id)
IPF/VMS 0x00000008 NT_VMS_LINKTIME
Link time: 2012-07-14T19:26:47
IPF/VMS 0x0000000e NT_VMS_LINKID (link id)
Linker id: Linker I02-38
IPF/VMS 0x00000025 NT_VMS_ORIG_DYN
Major id: 1, minor id: 3
Manip date : 2012-07-14T19:26:47
Link flags : 0x00000000000004a0
Header flags: 0x01000014
Image id : V1.0
IPF/VMS 0x00000008 NT_VMS_PATCHTIME
Patch time: 2012-07-14T19:26:47
If you carefully paid attention to the code, this is just 8 + 8 or 16 + 24 bytes I am concerned with (NT_VMS_IMGID above). So, unless I misunderstood it, your remark was purely theoretical. However to satisfy your past (maybe current) developer mind, I did address your remark in an update of the code. Practically speaking, this should have no influence onto the sake of the produced ELF image compared with previously.
Kind regards,
Philippe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-17-2012 12:18 PM
07-17-2012 12:18 PM
Re: Utility to change "image file identification"?
John,
You could only be correct provided the NT_VMS_IMGNAM + NT_VMS_GSTNAM .note subentries are so large that the NT_VMS_IMGID spans over two adjacent disk blocks AND the ELF image is not disk [re]written into a new file.
One can comment onto IMGNAM and GSTNAM physical limits on VMS.
Regards,
Philippe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-17-2012 01:49 PM
07-17-2012 01:49 PM
Re: Utility to change "image file identification"?
>>> the IA64 VMS Linker aligns the .note section on a disk block boundary
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2012 06:48 AM
07-18-2012 06:48 AM
Re: Utility to change "image file identification"?
Harmut and John,
Please do refrein yourself from thinking theoretically. Find me a single non corrupted .EXE which matches your hypothesis. I can't find any which does.
$ @notes_section.com
Number of .EXE scanned
Grand total of 455 directories, 4563 files.
$ type notes_section.com
$ create notes_section.gawk
{
blocksize = 512;
if (/^Notes at offset /) {
match($0,/^Notes at offset (.*) with length (.*):/,a);
if ((strtonum(a[1])%blocksize != 0) || (strtonum(a[2]) > blocksize)) {
# print "Alert : Note section not aligned on a block boundary or ...";
# print "Notes section length greater than a block size";
exit 44
}
else {
exit 0
}
}
}
$ write sys$output "Number of .EXE scanned"
$ dire/grand sys$sysdevice:[*...]*.EXE;
$ context = 10
$ set process/priv=bypass
$ loop:
$ file = f$search("sys$sysdevice:[*...]*.EXE;",context)
$ if file .eqs. "" then exit
$ pipe readelf --note 'file' | gawk -f notes_section.gawk
$ if $STATUS .eq. 44
$ then
$ write sys$output "Look at this ''file' file"
$ endif
$ goto loop
$ logout
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2012 02:44 PM
07-18-2012 02:44 PM
Re: Utility to change "image file identification"?
I'll refrain from thinking. I've done that for years... ask my wife.
In an .EXE, there is an upperbound for .note section size.
linktime + imgnam + imgid + linkid + imgbid + gstnam + orig_dyn + patchtime
That should always be under 512 (I didn't actually add the max values, I did some thinking instead)
For .OBJ files, the .note sections can theoreticallly (there's that word again) be much larger than 512. If the compilers decide to emit source file names, title text, and Pascal's "entity ident consistency check".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-19-2012 09:39 AM
07-19-2012 09:39 AM
Re: Utility to change "image file identification"?
For non-operating system executable images this idea is ducky. But, from past experience, munging around with the information in these areas for original .EXE files that are part of OpenVMS or it's layered products is generally what could be called A Bad Thing. There are several utilities that use the information contained within the executable header of O/S images that depend on the data being exactly what DEC/CPQ/HP sent.
Having said that...it is your (or your customer's) system and it can be modified however you wish. Just please be prepared with a backup of the disk or images if things stop working so you can restore what got clobbered. It would also be polite to let customer support know if you've made changes of this sort because tools they use will also be effectively neutered.
bob