Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #67404 > unrolled thread

Relocatable functions in C?

Back to article view | Back to comp.lang.c

Contents

  Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 09:57 -0700
    Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 10:13 -0700
      Re: Relocatable functions in C? Ken Brody <kenbrody@spamcop.net> - 2015-08-14 13:33 -0400
        Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-14 19:51 +0200
          Re: Relocatable functions in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 16:12 -0500
        Re: Relocatable functions in C? David Brown <david.brown@hesbynett.no> - 2015-08-15 16:17 +0200
    Re: Relocatable functions in C? Bartc <bc@freeuk.com> - 2015-08-14 18:29 +0100
    Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 11:37 -0700
      Re: Relocatable functions in C? Bartc <bc@freeuk.com> - 2015-08-14 19:43 +0100
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 11:46 -0700
          Re: Relocatable functions in C? Bartc <bc@freeuk.com> - 2015-08-14 19:57 +0100
            Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 11:59 -0700
              Re: Relocatable functions in C? jt@toerring.de (Jens Thoms Toerring) - 2015-08-14 20:27 +0000
            Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 12:01 -0700
      Re: Relocatable functions in C? Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-08-25 22:36 +0000
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 05:55 -0700
    Re: Relocatable functions in C? fir <profesor.fir@gmail.com> - 2015-08-14 12:57 -0700
      Re: Relocatable functions in C? fir <profesor.fir@gmail.com> - 2015-08-14 13:26 -0700
        Re: Relocatable functions in C? fir <profesor.fir@gmail.com> - 2015-08-14 13:39 -0700
          Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 13:46 -0700
          Re: Relocatable functions in C? fir <profesor.fir@gmail.com> - 2015-08-14 14:00 -0700
            Re: Relocatable functions in C? fir <profesor.fir@gmail.com> - 2015-08-14 15:07 -0700
              Re: Relocatable functions in C? fir <profesor.fir@gmail.com> - 2015-08-14 16:02 -0700
    Re: Relocatable functions in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-14 23:11 -0700
      Re: Relocatable functions in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-15 10:31 +0100
    Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 11:56 -0700
      Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:48 +0200
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 15:05 -0700
          Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 00:12 +0200
            Re: Relocatable functions in C? David Brown <david.brown@hesbynett.no> - 2015-08-16 16:09 +0200
        Re: Relocatable functions in C? Ian Collins <ian-news@hotmail.com> - 2015-08-16 10:47 +1200
          Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 01:09 +0200
      Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 15:07 -0700
      Re: Relocatable functions in C? jt@toerring.de (Jens Thoms Toerring) - 2015-08-15 22:09 +0000
        Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 00:21 +0200
          Re: Relocatable functions in C? jt@toerring.de (Jens Thoms Toerring) - 2015-08-15 23:44 +0000
            Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 02:25 +0200
              Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 02:34 +0200
              Re: Relocatable functions in C? jt@toerring.de (Jens Thoms Toerring) - 2015-08-16 01:11 +0000
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 15:26 -0700
          Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 15:36 -0700
            Re: Relocatable functions in C? jt@toerring.de (Jens Thoms Toerring) - 2015-08-15 23:29 +0000
              Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 16:34 -0700
    Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 17:03 -0700
      Re: Relocatable functions in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 02:32 +0200
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 18:25 -0700
      Re: Relocatable functions in C? jt@toerring.de (Jens Thoms Toerring) - 2015-08-16 01:26 +0000
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 18:38 -0700
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 18:49 -0700
      Re: Relocatable functions in C? Ian Collins <ian-news@hotmail.com> - 2015-08-16 14:04 +1200
        Re: Relocatable functions in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-15 20:19 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#67483

On Saturday, August 15, 2015 at 6:26:20 PM UTC-4, Rick C. Hodgin wrote:
> > ... But why would there
> > be "thousands" of DLLs - and even if there are, would they all
> > be loaded by your program at the same time?
> 
> I'm creating a new tool for hardware design, called Logician.  This
> tool will define and compile a piece of hardware using C, and not
> Verilog.  It also uses a particular GUI hookup mechanism I've defined
> which allows the complexities of attaching logic units to no longer
> be mechanical, but instead graphical.
> 
> You can see some preliminary designs here:

    https://github.com/RickCHodgin/libsf/tree/master/li386/logician/graphics

> And I intend to hook things up using something like Blender's 3D
> node editor, shown here:

The node editor demo begins at 0:25:

    https://www.youtube.com/watch?v=ZmrCoGj9m2Y

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#67488

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> On Saturday, August 15, 2015 at 6:26:20 PM UTC-4, Rick C. Hodgin wrote:
> > > ... But why would there
> > > be "thousands" of DLLs - and even if there are, would they all
> > > be loaded by your program at the same time?
> > 
> > I'm creating a new tool for hardware design, called Logician.  This
> > tool will define and compile a piece of hardware using C, and not
> > Verilog.  It also uses a particular GUI hookup mechanism I've defined
> > which allows the complexities of attaching logic units to no longer
> > be mechanical, but instead graphical.
> > 
> > You can see some preliminary designs here:

>     https://github.com/RickCHodgin/libsf/tree/master/li386/logician/graphics

> > And I intend to hook things up using something like Blender's 3D
> > node editor, shown here:

> The node editor demo begins at 0:25:

>     https://www.youtube.com/watch?v=ZmrCoGj9m2Y

Sorry to rain in on your parade, but that's all just graphics
stuff. That may be cool and all, but starting a complicated
project from thinking about how the final user interface will
look like is IMHO a recipe for failure. First solve the under-
lying problem, then work out how to present it to the user
(though, of course, it won't hurt to keep that also in mind in
the design phase). If you're up to developing anything but a
toy (and you mentioned "verilog" as something you want to top)
then it has to work also without a GUI and must be "programable"
- I guess you can be quite sure that people that actually do hard-
ware design will be capable of abstract thinking (they'll have to
be) and don't think in "pictures" to get their work done.

                         Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#67489

On Saturday, August 15, 2015 at 7:29:45 PM UTC-4, Jens Thoms Toerring wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > On Saturday, August 15, 2015 at 6:26:20 PM UTC-4, Rick C. Hodgin wrote:
> > > > ... But why would there
> > > > be "thousands" of DLLs - and even if there are, would they all
> > > > be loaded by your program at the same time?
> > > 
> > > I'm creating a new tool for hardware design, called Logician.  This
> > > tool will define and compile a piece of hardware using C, and not
> > > Verilog.  It also uses a particular GUI hookup mechanism I've defined
> > > which allows the complexities of attaching logic units to no longer
> > > be mechanical, but instead graphical.
> > > 
> > > You can see some preliminary designs here:
> 
> >     https://github.com/RickCHodgin/libsf/tree/master/li386/logician/graphics
> 
> > > And I intend to hook things up using something like Blender's 3D
> > > node editor, shown here:
> 
> > The node editor demo begins at 0:25:
> 
> >     https://www.youtube.com/watch?v=ZmrCoGj9m2Y
> 
> Sorry to rain in on your parade, but that's all just graphics
> stuff. That may be cool and all, but starting a complicated
> project from thinking about how the final user interface will
> look like is IMHO a recipe for failure. First solve the under-
> lying problem, then work out how to present it to the user
> (though, of course, it won't hurt to keep that also in mind in
> the design phase). If you're up to developing anything but a
> toy (and you mentioned "verilog" as something you want to top)
> then it has to work also without a GUI and must be "programable"
> - I guess you can be quite sure that people that actually do hard-
> ware design will be capable of abstract thinking (they'll have to
> be) and don't think in "pictures" to get their work done.
>                          Regards, Jens

You are a talented developer, and I wish you the best on your projects.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#67493

I have discovered I can use this type of file (very simple for the
sake of this test):

     int my_function(void)
     {
         return(-5);
     }

And this command line:

     gcc -masm=intel -S fred.c

...generated a file which I edited down manually for making a simpler
test.  The final fred.s file looked like this:

     -----[ Begin ]-----
	.file	"fred.c"
	.intel_syntax noprefix
	.text
	.globl	_my_function
	.def	_my_function;	.scl	2;	.type	32;	.endef
_my_function:
LFB0:
	mov	eax, -5
	ret
LFE0:
	.ident	"GCC: (GNU) 4.8.1"
     -----[ End ]-----

Next, I used this command to assemble and link the edited fred.s
file:

     gcc -nodefaultlibs -nostdlib -o fred.dll fred.s

It generates fred.dll, a 4 KB file.  Running fred.dll through the
objdump utility:

    objdump -x fred.dll > fred.dmp

...I get a 7 KB file, which contains this (pared down for display here):

     Sections:
     Idx Name          Size      VMA       LMA       File off  Algn
       0 .text         00000018  00401000  00401000  00000200  8 bytes
       1 .rdata        00000014  00402000  00402000  00000400  8 bytes
       2 .idata        00000014  00403000  00403000  00000600  8 bytes

Size shows the section is 0x18 bytes long, and File off shows it
begins at offset 0x200 in the .dll file itself.  I wasn't sure if
this was right or not, so I went to examine it manually.

Looking at the contents of the fred.dll file in a hex editor, I find
this content at offset 0x200:

     00000200 .. B8 FB FF FF FF C3 90 90 .. FF FF FF FF 00 00 00 00
     00000210 .. FF FF FF FF 00 00 00 00 .. 00 00 00 00 00 00 00 00

Running those bytes through a disassembler, I see that it disassembles
to these assembly opcodes:

     B8 FB FF FF FF   mov         eax,0FFFFFFFBh (-5)
     C3               ret
     ; Padding bytes to round to nearest 8-byte alignment:
     90               nop
     90               nop
     ; The remaining bytes are just padding

-----
This gives me a way to compile code, run it through objmap, get the
offset and size, and load it in directly from the DLL without having
to use any loaders.  I do not have to use any global memory, and can
pass everything in by parameters.  I discovered by using -fPIC that
the compiler told me it's ignored, that all code is generated as
position independent by default ... which is good news.

The source code I'll be compiling is Logician source code.  It's
nearly identical to C, but adds some features for more easily
accessing bits, and interfacing with some of the primitive types
I've defined.  As such, it will be parsed into things that I am
aware of, so the function calls I need can be created in a passed
environment structure like this:

    struct SLogicianEnvironment
    {
        char*   (*le_printf)(...);
        // And so on...
    };

I plan on passing a pointer to this structure which is populated
and exposes the things the custom-created-on-the-fly code will need
for all of its callbacks.  And, the source code I generate will
include that structure, and the compiler will reference everything
through it.

    void my_function(SLogicianEnvironment* env)
    {
        // Instead of my program using printf(...), it will use:
        env->le_printf("Hello, world\n");
    }

Now, I have to tackle the issue of having executable code running
in allocated data.  But, apart from that everything is working.  If
worse comes to worst, I'll just write a kernel-level driver which
handles that part for me.

It looks like I'm off and running.  We'll see how I finish.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#67498

Le 16/08/2015 02:03, Rick C. Hodgin a écrit :
> This gives me a way to compile code, run it through objmap, get the
> offset and size, and load it in directly from the DLL without having
> to use any loaders.

Of course.

Try this:

int hello(void)  {printf("hello\n");}

And you will see that

1) the call has an offset that you need to fix
2) Accessing the literal string "hello" has an address you need to fix

Etc.

Note that all instructions are VARIABLE LENGTH in the x86.

Have fun Rick.

[toc] | [prev] | [next] | [standalone]

#67502

On Saturday, August 15, 2015 at 8:32:55 PM UTC-4, jacobnavia wrote:
> Le 16/08/2015 02:03, Rick C. Hodgin a écrit :
> > This gives me a way to compile code, run it through objmap, get the
> > offset and size, and load it in directly from the DLL without having
> > to use any loaders.
> 
> Of course.
> 
> Try this:
> 
> int hello(void)  {printf("hello\n");}
> 
> And you will see that
> 
> 1) the call has an offset that you need to fix
> 2) Accessing the literal string "hello" has an address you need to fix

Remembering that I am first compiling the Logician source code, which
is then translated into C source code and Logician internal-resource
function calls, the solutions I am using is as follows:

    1) By parsing the source file I am able to determine function
       calls. If I find known functions, I fix them up to point through
       the env-> parameter directly.  If any unknowns are encountered,
       I generate a second source file which is compiled separately as
       a stand-alone standard DLL.  It contains a 1:1 ratio of the
       custom list of functions, and a structure which populates an
       array which is then a list of addresses generated at runtime.

       I call that function one time after each re-compile, or when
       Logician first starts up and the user begins running the piece
       of hardware in simulation, and then I provide that pointer as
       input to the passed env environment variable.  In that way,
       the DLL only needs to be loaded, run once, and then it can be
       closed and even deleted if need be, though I'll probably just
       keep it in a cache and rebuild it only if it's stale.

       In any event, the address generator creates the list of dynamic
       addresses for the functions it been setup to inquire, in the
       order it's been setup to inquire of them.

       Then back in the original source file, I markup the custom
       function calls so that it calls the function by name through
       a custom structure I create by using a union containing a 32-bit
       unsigned int, with one entry for every function prototype
       definition that was encountered, referencing it then through
       a custom instance of that structure which comes in as a parameter
       I reuse this same variable for each line of source code,
       populating the unsigned int as needed for the next call.  And
       if more than one function call is encountered on each line of
       source code, I use two or more variables.

    2) By parsing the source file, I am able to extract all
       data and populate their size, content, and addresses
       using the same second DLL I created in 1).  Then I am
       able to pass a pointer to the data, and reference
       everything indirectly through the custom struct that
       was created.

By doing all of this in source code, I let the compiler do all
the hard work for me.  And, I also gain the ability to (1) document
resource usage for the process, and (2) allow the simulation to
literally be paused, saved to disk, and later restored exactly as
it was when they last ran it.

All done on-the-fly, allowing for real edit-and-continue to take
place because the offset, size, length, of every function and
variable is handled indirectly, meaning I can compare the before-
and-after diffs between two versions, and literally migrate running
data in memory as I go.

Not too shabby, yes?

> Etc.
> Note that all instructions are VARIABLE LENGTH in the x86.
> Have fun Rick.

I do appreciate your input, Jacob.

Maybe there's something in this project methodology that you might
be able to use.  That's why I write all of my projects under the
(Public Benefit) PBL source code license:

    http://www.libsf.org/licenses/

It's a Public Domain license with one caveat:  self-accountability
to God in honoring my request that the software be kept open, as
free and libre source code for others to share, use, enhance, and
distribute, just as you received it from me.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#67503

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> I have discovered I can use this type of file (very simple for the
> sake of this test):

>      int my_function(void)
>      {
>          return(-5);
>      }

> And this command line:

>      gcc -masm=intel -S fred.c

> ...generated a file which I edited down manually for making a simpler
> test.  The final fred.s file looked like this:

>      -----[ Begin ]-----
>         .file   "fred.c"
>         .intel_syntax noprefix
>         .text
>         .globl  _my_function
>         .def    _my_function;   .scl    2;      .type   32;     .endef
> _my_function:
> LFB0:
>         mov     eax, -5
>         ret
> LFE0:
>         .ident  "GCC: (GNU) 4.8.1"
>      -----[ End ]-----

> Next, I used this command to assemble and link the edited fred.s
> file:

>      gcc -nodefaultlibs -nostdlib -o fred.dll fred.s

> It generates fred.dll, a 4 KB file.  Running fred.dll through the
> objdump utility:

>     objdump -x fred.dll > fred.dmp

> ...I get a 7 KB file, which contains this (pared down for display here):

>      Sections:
>      Idx Name          Size      VMA       LMA       File off  Algn
>        0 .text         00000018  00401000  00401000  00000200  8 bytes
>        1 .rdata        00000014  00402000  00402000  00000400  8 bytes
>        2 .idata        00000014  00403000  00403000  00000600  8 bytes

> Size shows the section is 0x18 bytes long, and File off shows it
> begins at offset 0x200 in the .dll file itself.  I wasn't sure if
> this was right or not, so I went to examine it manually.

> Looking at the contents of the fred.dll file in a hex editor, I find
> this content at offset 0x200:

>      00000200 .. B8 FB FF FF FF C3 90 90 .. FF FF FF FF 00 00 00 00
>      00000210 .. FF FF FF FF 00 00 00 00 .. 00 00 00 00 00 00 00 00

> Running those bytes through a disassembler, I see that it disassembles
> to these assembly opcodes:

>      B8 FB FF FF FF   mov         eax,0FFFFFFFBh (-5)
>      C3               ret
>      ; Padding bytes to round to nearest 8-byte alignment:
>      90               nop
>      90               nop
>      ; The remaining bytes are just padding

> -----
> This gives me a way to compile code, run it through objmap, get the
> offset and size, and load it in directly from the DLL without having
> to use any loaders.  I do not have to use any global memory, and can
> pass everything in by parameters.  I discovered by using -fPIC that
> the compiler told me it's ignored, that all code is generated as
> position independent by default ... which is good news.

On a x86-64 doing

gcc -shared -fpic -o fred.so fred.c

gives you the same results (also a file of a bit more than 7 kB).
From

  objdump -x fred.so I find

I get a line line with

  0000000000000668 g     F .text  0000000000000006              my_function

And, voila, at 0x668 in that file I have

  00000660: e94b ffff ff90 9090 b8fb ffff ffc3 9090  .K..............

where the length of 6 bytes for that function actually looks
correct (it just includes the '0xc3', i.e. "return"). And, if
you start having something in the there that does jumps it
should be position-independent, which your approach rather
likely doesn't guarantee.

> Now, I have to tackle the issue of having executable code running
> in allocated data.  But, apart from that everything is working.  If
> worse comes to worst, I'll just write a kernel-level driver which
> handles that part for me.

The kernel probably won't do much for you in that respect with
a driver. But, probably, if your program runs with root permis-
sions, there are ways to fiddle with the page flags. Much fun
figuring out that and then getting people to install your pro-
gram so that it always runs with full root permission. But, then,
for installing a kernel driver to get your program to run at all,
would require the same amount of trust...

Simply doing a dlopen() and then dlsym() on 'my_function'
would avoid all that hassle (as well as taking care of fixing
all addresses of functions that may be called from within
'my_function'). But if you want to do it the hard way no-one
is keeping you back;-) Just better start reading lots and
lots of documentation. And, most important, keep in mind that
all your "exoeriments" are done on a certain machine with a
certain OS. Make up your mind what's your target! No shame in
saying "This program will only run under archtecture X when
using operating system Y", but make that a decision, not
something that's merely the result of not understanding what
you were doing!
                         Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#67504

On Saturday, August 15, 2015 at 9:26:50 PM UTC-4, Jens Thoms Toerring wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > I have discovered I can use this type of file (very simple for the
> > sake of this test):
> 
> >      int my_function(void)
> >      {
> >          return(-5);
> >      }
> 
> > And this command line:
> 
> >      gcc -masm=intel -S fred.c
> 
> > ...generated a file which I edited down manually for making a simpler
> > test.  The final fred.s file looked like this:
> 
> >      -----[ Begin ]-----
> >         .file   "fred.c"
> >         .intel_syntax noprefix
> >         .text
> >         .globl  _my_function
> >         .def    _my_function;   .scl    2;      .type   32;     .endef
> > _my_function:
> > LFB0:
> >         mov     eax, -5
> >         ret
> > LFE0:
> >         .ident  "GCC: (GNU) 4.8.1"
> >      -----[ End ]-----
> 
> > Next, I used this command to assemble and link the edited fred.s
> > file:
> 
> >      gcc -nodefaultlibs -nostdlib -o fred.dll fred.s
> 
> > It generates fred.dll, a 4 KB file.  Running fred.dll through the
> > objdump utility:
> 
> >     objdump -x fred.dll > fred.dmp
> 
> > ...I get a 7 KB file, which contains this (pared down for display here):
> 
> >      Sections:
> >      Idx Name          Size      VMA       LMA       File off  Algn
> >        0 .text         00000018  00401000  00401000  00000200  8 bytes
> >        1 .rdata        00000014  00402000  00402000  00000400  8 bytes
> >        2 .idata        00000014  00403000  00403000  00000600  8 bytes
> 
> > Size shows the section is 0x18 bytes long, and File off shows it
> > begins at offset 0x200 in the .dll file itself.  I wasn't sure if
> > this was right or not, so I went to examine it manually.
> 
> > Looking at the contents of the fred.dll file in a hex editor, I find
> > this content at offset 0x200:
> 
> >      00000200 .. B8 FB FF FF FF C3 90 90 .. FF FF FF FF 00 00 00 00
> >      00000210 .. FF FF FF FF 00 00 00 00 .. 00 00 00 00 00 00 00 00
> 
> > Running those bytes through a disassembler, I see that it disassembles
> > to these assembly opcodes:
> 
> >      B8 FB FF FF FF   mov         eax,0FFFFFFFBh (-5)
> >      C3               ret
> >      ; Padding bytes to round to nearest 8-byte alignment:
> >      90               nop
> >      90               nop
> >      ; The remaining bytes are just padding
> 
> > -----
> > This gives me a way to compile code, run it through objmap, get the
> > offset and size, and load it in directly from the DLL without having
> > to use any loaders.  I do not have to use any global memory, and can
> > pass everything in by parameters.  I discovered by using -fPIC that
> > the compiler told me it's ignored, that all code is generated as
> > position independent by default ... which is good news.
> 
> On a x86-64 doing
> 
> gcc -shared -fpic -o fred.so fred.c
> 
> gives you the same results (also a file of a bit more than 7 kB).
> From
> 
>   objdump -x fred.so I find
> 
> I get a line line with
> 
>   0000000000000668 g     F .text  0000000000000006              my_function
> 
> And, voila, at 0x668 in that file I have
> 
>   00000660: e94b ffff ff90 9090 b8fb ffff ffc3 9090  .K..............
> 
> where the length of 6 bytes for that function actually looks
> correct (it just includes the '0xc3', i.e. "return"). And, if
> you start having something in the there that does jumps it
> should be position-independent, which your approach rather
> likely doesn't guarantee.
> 
> > Now, I have to tackle the issue of having executable code running
> > in allocated data.  But, apart from that everything is working.  If
> > worse comes to worst, I'll just write a kernel-level driver which
> > handles that part for me.
> 
> The kernel probably won't do much for you in that respect with
> a driver. But, probably, if your program runs with root permis-
> sions, there are ways to fiddle with the page flags. Much fun
> figuring out that and then getting people to install your pro-
> gram so that it always runs with full root permission. But, then,
> for installing a kernel driver to get your program to run at all,
> would require the same amount of trust...
> 
> Simply doing a dlopen() and then dlsym() on 'my_function'
> would avoid all that hassle (as well as taking care of fixing
> all addresses of functions that may be called from within
> 'my_function'). But if you want to do it the hard way no-one
> is keeping you back;-) Just better start reading lots and
> lots of documentation. And, most important, keep in mind that
> all your "exoeriments" are done on a certain machine with a
> certain OS. Make up your mind what's your target! No shame in
> saying "This program will only run under archtecture X when
> using operating system Y", but make that a decision, not
> something that's merely the result of not understanding what
> you were doing!

I have considered using the methodology you propose, however,
there are some difficulties.  First, I'm not sure how taxing it
would be on the OS to have a couple thousand separate DLLs
linked to a single project.  I think it will be an issue, but I
haven't tested it so I could be wrong.

Next, I want to be able to pause my simulation at any point,
save it to disk, and then restore the simulation and resume from
where it was across separate instances of Logician which may be
on different machines, or run on different days.

My long-term targets are also to move away from GCC and use my own
RDC compiler.  Because this is a feature I place value on, and am
needing, I will directly incorporate it into my RDC, which will
fully integrate this ability without the fixups I'm forced to
employ today.

I try to look at the big picture, and make choices which go with
where I want to take the Liberty Software Foundation ultimately,
and not just the needs of the current project.  It's definitely
more work to do it that way, but I'm looking at the payoff...
having these tools available for everybody to use in the long term.
For me, that's worth the extra difficulty I'll put myself through
in the short-term.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#67506

On Saturday, August 15, 2015 at 9:26:50 PM UTC-4, Jens Thoms Toerring wrote:
> ....And, if
> you start having something in the there that does jumps it
> should be position-independent, which your approach rather
> likely doesn't guarantee.

I was using the -fPIC flag to begin, but according to GCC it is
ignored.  The warning message say that all code it generates is
position independent, so it's not needed.  As such, all jumps
should be appropriate.  We'll see though if the GCC warning is
appropriate and valid. :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#67512

Rick C. Hodgin wrote:
> I have discovered I can use this type of file (very simple for the
> sake of this test):

I'm not sure if there is a windows equivalent, but most systems that use 
ELF can use libelf to pull all of the information you require at run time.

<snip>

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#67519

On Saturday, August 15, 2015 at 10:04:09 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > I have discovered I can use this type of file (very simple for the
> > sake of this test):
> 
> I'm not sure if there is a windows equivalent, but most systems that use 
> ELF can use libelf to pull all of the information you require at run time.

Thank you, Ian.  That would be wonderful.  I'll look into it.

As far as I can tell so far, it's not available on my system under
Cygwin or MinGW, at least not without building it from sources.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web