[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Any progress with FIS GT.M?



On 06/18/2012 12:00 PM, Bhaskar, K.S wrote:
> [KSB] I'll see about getting you that information - it is possible
> that none of the developers knows that answer right off the top of
> his head and some research will be needed.  But be aware that you
> cannot simply "patch it" to look for the original .m file in the
> same directory without breaking a large number of existing
> applications that use GT.M, since it is quite common for the source
> and object files to not be in the same directory.  What you are
> really asking for is an enhancement to GT.M.  I can think of a
> couple of ways to approach the enhancement, but none of them is
> trivial.  For example, one could add an environment variable to tell
> the compiler to use a relative path to the source instead of an
> absolute path, or one could provide an option to special case the
> path if the source module is in the directory pointed to by
> $gtm_dist.

I don't think we need any change to the behavior of object file
loading/linking.  The goal is to compile .m to .o in a DESTDIR.
We do not need to load/run the resulting .o files from that location.
We only need the stored path to the .m to point to the final path
in which the sources will be put when the package is installed.
When gtm loads a .o after installation on the end user's system
it will find the .m where it expects with no change in search
behavior.

Here is a patch series that solves this problem.  I've only done
some lightweight/manual testing with this.  The first patch
refactors both i386 and x86_64 code paths that emit the path to
the source file into the object file to send source file path
lookup through a common point (in obj_source.c).  The second
patch modifies this common point to read a 'gtm_destdir' env var
and strip the prefix it names from source file paths.

The net diffstat of the series is:

 sr_i386/obj_file.c      |    8 ++++++--
 sr_unix/comp_lits.c     |   11 +++++++----
 sr_unix/obj_file.c      |   10 ++++++----
 sr_unix/obj_source.c    |   25 +++++++++++++++++++++++++
 sr_unix/obj_source.h    |   12 ++++++++++++
 sr_unix_nsb/comp_lits.c |   11 +++++++----
 6 files changed, 63 insertions(+), 14 deletions(-)

I tried to follow style and portability conventions I found in
existing sources, but this is the first time I've read the code
so the patches may need adjustment for such things.  The series
also doesn't touch any documentation.

-Brad
>From 9e807f2434e3425f0a4e71860ae051deb7709e8f Mon Sep 17 00:00:00 2001
Message-Id: <9e807f2434e3425f0a4e71860ae051deb7709e8f.1340044290.git.brad.king@kitware.com>
From: Brad King <brad.king@kitware.com>
Date: Mon, 18 Jun 2012 14:04:28 -0400
Subject: [PATCH 1/2] Refactor object file source name storage

Teach 'comp_lits' and 'emit_literals' to lookup the source file name
through a new 'obj_source' structure.  This will allow the source file
to be modified before storage in the object file.
---
 sr_i386/obj_file.c      |    8 ++++++--
 sr_unix/comp_lits.c     |   11 +++++++----
 sr_unix/obj_file.c      |   10 ++++++----
 sr_unix/obj_source.c    |   12 ++++++++++++
 sr_unix/obj_source.h    |   12 ++++++++++++
 sr_unix_nsb/comp_lits.c |   11 +++++++----
 6 files changed, 50 insertions(+), 14 deletions(-)
 create mode 100644 sr_unix/obj_source.c
 create mode 100644 sr_unix/obj_source.h

diff --git a/sr_i386/obj_file.c b/sr_i386/obj_file.c
index da40b0e..8b7278a 100644
--- a/sr_i386/obj_file.c
+++ b/sr_i386/obj_file.c
@@ -30,6 +30,7 @@
 #include "gtmio.h"
 #include "mmemory.h"
 #include "obj_file.h"
+#include <obj_source.h>
 
 LITREF char gtm_release_name[];
 LITREF int4 gtm_release_name_len;
@@ -444,8 +445,11 @@ void emit_literals(void)
 		emit_immed(PADCHARS, padsize);
 		offset += padsize;
 	}
-	emit_immed(source_file_name, source_name_len);
-	offset += source_name_len;
+	{
+		struct obj_source s = get_obj_source();
+		emit_immed(s.name, s.len);
+		offset += s.len;
+	}
 	/* comp_lits aligns the start of routine_name on a NATIVE_WSIZE boundary.*/
 	padsize = PADLEN(offset, NATIVE_WSIZE);
 	if (padsize)
diff --git a/sr_unix/comp_lits.c b/sr_unix/comp_lits.c
index 3f7b89b..7e8f67f 100644
--- a/sr_unix/comp_lits.c
+++ b/sr_unix/comp_lits.c
@@ -14,10 +14,10 @@
 #include <rtnhdr.h>
 #include "mdq.h"
 #include "stringpool.h"
+#include <obj_source.h>
 
 GBLREF mliteral		literal_chain;
 GBLREF spdesc		stringpool;
-GBLREF unsigned short	source_name_len;
 GBLREF mident		routine_name;
 
 GBLDEF uint4		lits_text_size, lits_mval_size;
@@ -34,9 +34,12 @@ void comp_lits(rhdtyp *rhead)
 	 * following the literal text pool and is considered part of that text pool.*/
 	offset = (stringpool.free - stringpool.base);
 	offset += PADLEN(offset, NATIVE_WSIZE);
-	rhead->src_full_name.len = source_name_len;
-	rhead->src_full_name.addr = (char *)offset;
-	offset += source_name_len;
+	{
+		struct obj_source s = get_obj_source();
+		rhead->src_full_name.len = s.len;
+		rhead->src_full_name.addr = (char *)offset;
+		offset += s.len;
+	}
 	offset += PADLEN(offset, NATIVE_WSIZE);
 	rhead->routine_name.len = routine_name.len;
 	rhead->routine_name.addr = (char *)offset;
diff --git a/sr_unix/obj_file.c b/sr_unix/obj_file.c
index b8d7709..4b576ba 100644
--- a/sr_unix/obj_file.c
+++ b/sr_unix/obj_file.c
@@ -28,6 +28,7 @@
 #include "gtmio.h"
 #include "mmemory.h"
 #include "obj_file.h"
+#include <obj_source.h>
 
 GBLREF char		object_file_name[];
 GBLREF short		object_name_len;
@@ -38,8 +39,6 @@ GBLREF boolean_t	run_time;
 GBLREF int4		lits_text_size, lits_mval_size;
 GBLREF unsigned char	*runtime_base;
 GBLREF mliteral		literal_chain;
-GBLREF char		source_file_name[];
-GBLREF unsigned short	source_name_len;
 GBLREF mident		routine_name;
 GBLREF spdesc		stringpool;
 GBLREF int4		linkage_size;
@@ -381,8 +380,11 @@ void	emit_literals(void)
 		emit_immed(PADCHARS, padsize);
 		offset += padsize;
 	}
-	emit_immed(source_file_name, source_name_len);
-	offset += source_name_len;
+	{
+		struct obj_source s = get_obj_source();
+		emit_immed(s.name, s.len);
+		offset += s.len;
+	}
 	padsize = (uint4)(PADLEN(offset, NATIVE_WSIZE)); /* comp_lits aligns the start of routine_name on NATIVE_WSIZE boundary.*/
 	if (padsize)
 	{
diff --git a/sr_unix/obj_source.c b/sr_unix/obj_source.c
new file mode 100644
index 0000000..55f79b0
--- /dev/null
+++ b/sr_unix/obj_source.c
@@ -0,0 +1,12 @@
+#include "mdef.h"
+
+#include "obj_source.h"
+
+GBLREF char		source_file_name[];
+GBLREF unsigned short	source_name_len;
+
+struct obj_source get_obj_source(void)
+{
+	struct obj_source sn = {source_file_name, source_name_len};
+	return sn;
+}
diff --git a/sr_unix/obj_source.h b/sr_unix/obj_source.h
new file mode 100644
index 0000000..138fa5a
--- /dev/null
+++ b/sr_unix/obj_source.h
@@ -0,0 +1,12 @@
+#ifndef __OBJ_SOURCE_H__
+#define __OBJ_SOURCE_H__
+
+struct obj_source
+{
+	char* name;
+	unsigned short len;
+};
+
+struct obj_source get_obj_source(void);
+
+#endif
diff --git a/sr_unix_nsb/comp_lits.c b/sr_unix_nsb/comp_lits.c
index 06df2e2..2e64bef 100644
--- a/sr_unix_nsb/comp_lits.c
+++ b/sr_unix_nsb/comp_lits.c
@@ -14,10 +14,10 @@
 #include "rtnhdr.h"
 #include "mdq.h"
 #include "stringpool.h"
+#include <obj_source.h>
 
 GBLREF mliteral 	literal_chain;
 GBLREF spdesc 		stringpool;
-GBLREF unsigned short 	source_name_len;
 GBLREF mident		routine_name;
 
 GBLDEF uint4 		lits_size, lit_addrs;
@@ -31,9 +31,12 @@ rhdtyp *rhead;
 
 	offset = stringpool.free - stringpool.base;
 	offset += PADLEN(offset, NATIVE_WSIZE);
-	rhead->src_full_name.len = source_name_len;
-	rhead->src_full_name.addr = (char *)offset;
-	offset += source_name_len;
+	{
+		struct obj_source s = get_obj_source();
+		rhead->src_full_name.len = s.len;
+		rhead->src_full_name.addr = (char *)offset;
+		offset += s.len;
+	}
 	offset += PADLEN(offset, NATIVE_WSIZE);
 	rhead->routine_name.len = routine_name.len;
 	rhead->routine_name.addr = (char *)offset;
-- 
1.7.10

>From 74aa25e0751a28a08202a13f9f13c79e532c29ab Mon Sep 17 00:00:00 2001
Message-Id: <74aa25e0751a28a08202a13f9f13c79e532c29ab.1340044290.git.brad.king@kitware.com>
In-Reply-To: <9e807f2434e3425f0a4e71860ae051deb7709e8f.1340044290.git.brad.king@kitware.com>
References: <9e807f2434e3425f0a4e71860ae051deb7709e8f.1340044290.git.brad.king@kitware.com>
From: Brad King <brad.king@kitware.com>
Date: Mon, 18 Jun 2012 14:18:32 -0400
Subject: [PATCH 2/2] Support source-to-object compilation in a DESTDIR

If environment variable 'gtm_destdir' is set, treat it as a prefix to be
removed from any source file paths contained inside it.  This will allow
sources to be compiled in a DESTDIR for packaging such that the object
files will find their sources in the final install prefix after
distribution.
---
 sr_unix/obj_source.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/sr_unix/obj_source.c b/sr_unix/obj_source.c
index 55f79b0..8fc4250 100644
--- a/sr_unix/obj_source.c
+++ b/sr_unix/obj_source.c
@@ -1,3 +1,5 @@
+#include "gtm_stdlib.h"
+#include "gtm_string.h"
 #include "mdef.h"
 
 #include "obj_source.h"
@@ -8,5 +10,16 @@ GBLREF unsigned short	source_name_len;
 struct obj_source get_obj_source(void)
 {
 	struct obj_source sn = {source_file_name, source_name_len};
+	char* gtm_destdir = getenv("gtm_destdir");
+	if(gtm_destdir)
+	{
+		/* Strip the destdir prefix from sources inside it.  */
+		size_t const ddlen = strlen(gtm_destdir);
+		if(strncmp(sn.name, gtm_destdir, ddlen) == 0)
+		{
+			sn.name += ddlen;
+			sn.len -= ddlen;
+		}
+	}
 	return sn;
 }
-- 
1.7.10


Reply to: