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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#67431

W dniu piątek, 14 sierpnia 2015 22:39:56 UTC+2 użytkownik fir napisał:
> W dniu piątek, 14 sierpnia 2015 22:26:55 UTC+2 użytkownik fir napisał:
> > though it may be sait that such relocation 
> > of functions probably is not of primary usage..
> > unlike cpu kernels (hotspots) (which abrash and some was trying - in older era of p4 though iirc) .. and relocation of static arrays (which i was sayin on already and which could be a potentailly good usage)
> > 
> > as far as i can see such runtime relocation seem to be whole feasible (by compilers generating hidden functions with hidden arrays of fixups for each one element that has to be relocable - (probably some may wrote it explicitely too, but hand collecting of fixups could be burdensome))
> 
> it could be interesting exercise though
> 
> anybode able to wrote that?
> 
> const int taba_x_max = 100;
> const int taba_y_max = 100;
> 
> float taba[taba_y_max ][taba_x_max ];
> 
> void fill_taba(float value)
> {
>   for(int j=0; j<taba_x_max; j++)
>    for(int i=0; i<taba_x_max; i++)
>    {
>      taba[j][i] = value;
>    }
>  
> }
> 
> void resize_taba(int new_x, new_y)
> {
>   //realloc taba and fixup its users
> }
> 
> ?
> 
> (probably there might be some problem with consts - not changeable maybe and optimised away in loops (yet not c) - but you may eventually use ints and defines instead consts 
> use defines in array creation, ints as a size info in clients...
> 
> so ?

How it would look like.. 
one would need to malloc new chunk of ram,
free the old one (though Im not sure how to dealloc static array ram, so it may be that will be just leave unused and wasted)
then one just need to fixup taba reference
to this given by malloc 9and yet revrite sizez to new ones, this is easy) - this is harder
part as i probably cannot know for sure
the adres of taba reference in fill_taba body.. (im not sure)
i may probably - check this in binary debugger
of run some binary search on this body 
searching for bytes of old value of adress of taba then fixup it.. the debugger way seem more reliable but also more faliable (on changing compiler switches etc)

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

#67435

ps i made such code

#include<stdlib.h>
#include<stdio.h>
#include<windows.h>

 int taba_x_max = 100;
 int taba_y_max = 100;

float taba[100 ][100];

float fill_taba(float value)
{
  float sum = 0;

  for(int j=0; j<taba_y_max; j++)
   for(int i=0; i<taba_x_max; i++)
   {
     taba[j][i] = value;
     sum+= value;
   }
   return sum;

}

void resize_taba(int new_x, int new_y)
{
  //realloc taba and fixup its users
  void* newa =(void*) malloc(new_x*new_y*4);
  taba_x_max = new_x;
  taba_y_max = new_y;
  int* t = (int*)0x00401375;

  DWORD dwProtection, dwProtection2;
  VirtualProtect(t, 4, PAGE_READWRITE, &dwProtection);
  *t = (int) newa;

  VirtualProtect(t, 4, dwProtection, &dwProtection2);

}

int main()
{
 float a = fill_taba(1);

 printf("\n%p", taba);


  printf("\n%f", a);

  resize_taba(1000,1000);
  a =  fill_taba(2);
  printf("\n%f", a);

}

it seem to work as far as i can be sure from
reading good results and behaving as expected
(it crashes when i do not changed memory page attributes, when changed seem to work, not crashes
the fixup adress 0x00401375;is taken from debugger

it it is okay this is example of 'small miracle' of realoking a static array in c

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

#67437

W dniu sobota, 15 sierpnia 2015 00:07:38 UTC+2 użytkownik fir napisał:
> 
> it it is okay this is example of 'small miracle' of realoking a static array in c

ps
ofc oryginal static area should be yet freed but im not sure how to free it, depends how loader allocates that - virtual free? 
i will ask on stack

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

#67446

On Friday, August 14, 2015 at 5:58:09 PM UTC+1, Rick C. Hodgin wrote:
> If I create a library function, is there a way to tell a C compiler
> to make that function relocatable so that the binary code for its
> func() { ... } block can be copied from one location to another in
> memory, and even replicated at will?
>
Firstly, I recommend that you look at Tiny CC.
It's a C compiler and interpreter. Running it in interpreter mode
might well be the best answer.

There's no standard way to make a function relocatable, or to get
its size in memory. Messing about with executables is an invitation
to virus writers, and modern OSes tend to put some security in to 
made it hard to execute machine code in buffers generated on the fly.

However it's not hard in principle to make sure that all jumps
and memory accesses are either relative or patchable, and plenty
of compilers do it because plenty of systems require position-
independent code. But if there is a pragma, it will be buried
away somewhere deep in the documentation. It's not something the
normal user usually needs to bother with.

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

#67451

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, August 14, 2015 at 5:58:09 PM UTC+1, Rick C. Hodgin wrote:
>> If I create a library function, is there a way to tell a C compiler
>> to make that function relocatable so that the binary code for its
>> func() { ... } block can be copied from one location to another in
>> memory, and even replicated at will?
>>
> Firstly, I recommend that you look at Tiny CC.
> It's a C compiler and interpreter. Running it in interpreter mode
> might well be the best answer.

TinyCC is not an interpreter, but it has a "script mode" -- meaning that
is has support for Unix's #! syntax.  But the scripts you write are just
C source files that get compiled.

But I agree that it's worth a look.  It's fast, free (both senses) and
light-weight.

<snip>
-- 
Ben.

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

#67457

For my needs on this, I have realized that I probably could use DLLs.
I'm reticent though because there may be an issue as I'll likely have
thousands of separate DLLs loaded at one time on large projects, and
that may be a significant burden on the operating system.  Perhaps
not.

For now I think I'll stick with GCC and -fPIC creating one function
at a time with all parameters passed in to access global variables,
and callback functions, etc.  This will allow me to load-from-then-close
the library file which has the program content, and then I'm just
dealing with malloc() and free() for live changes.

-----
I'm having a dry spell today.  I feel like an artist sitting in front
of a canvas wanting to paint, but no inspiration is coming. :-)
Happens to me sometimes.  Other times I can't shut it off, and it
causes me stress in my life due to lack of sleep and what have you.

I can relate very strongly to Charlie in the TV show Numb3rs, Season
1, Episode 2, "Uncertainty Principle", beginning around 16 minutes in,
when Charlie's telling Professor Fleinhardt and Don about how he can't
turn his thinking on or off at times, and that he has to follow things
thru where the inspiration leads him.  Around 19 minutes he says:

    "Please understand.  Sometimes I can't choose what I work on.
     I can't follow thru on a line of thinking just because I want
     to, or because it's needed.  I have to work on what's in my
     head.  And right now, this is what's in my head."

I feel like that on many things in my life, and many of these things
I have come up with for Visual FreePro, for the LibSF 386-x40 CPU,
for RDC, etc., they aren't my thoughts, meaning I didn't just think
them thru.  Instead, they came to me as fully-formed inspiration,
deposited in my thoughts without me having to consider it.  And this
is a recurring theme for me, and something that always amazes me.
The same thing happens in music, and in solutions to various things
which come up in my life.  It's really quite something.  I am on an
ongoing basis consistently amazed by how that process works, and I
state to everybody:  "It's not me."  These are things being given
to me, and I am running with them at each point where the inspiration
strikes.

Does anybody else experience this in creativity in design?

Best regards,
Rick C. Hodgin

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

#67474

Le 15/08/2015 20:56, Rick C. Hodgin a écrit :
> I'm having a dry spell today.  I feel like an artist sitting in front
> of a canvas wanting to paint, but no inspiration is coming.:-)

Look. I did that several years ago.

1) I wrote a software that can load an object file into memory and link 
it in the fly.

2) I wrote a JIT. Just pass it a buffer with C code.

#include <jit.h>

typedef 	void (*Function)(void);
int main(void)
{
   Function sayHello = compile("int main(void){printf(\"Hello\\n\");}");
   sayHello();
}

I used the Jit for a pharma industry customer that compiles chemical 
formulae calculations.

And many others, quite a useful software.


jacob

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

#67476

On Saturday, August 15, 2015 at 5:48:15 PM UTC-4, jacobnavia wrote:
> Le 15/08/2015 20:56, Rick C. Hodgin a écrit :
> > I'm having a dry spell today.  I feel like an artist sitting in front
> > of a canvas wanting to paint, but no inspiration is coming.:-)
> 
> Look. I did that several years ago.
> 
> 1) I wrote a software that can load an object file into memory and link 
> it in the fly.
> 
> 2) I wrote a JIT. Just pass it a buffer with C code.
> 
> #include <jit.h>
> 
> typedef 	void (*Function)(void);
> int main(void)
> {
>    Function sayHello = compile("int main(void){printf(\"Hello\\n\");}");
>    sayHello();
> }
> 
> I used the Jit for a pharma industry customer that compiles chemical 
> formulae calculations.
> 
> And many others, quite a useful software.
> 
> jacob

That is almost exactly what I have planned, except that my "compile()"
function will have to parse Logician source code, converting it to a
series of C function call-backs into Logician's main algorithms, along
with the ability to be called with line number execution and single-
step debugging abilities.

I'm glad to hear someone else has already done on-the-fly compiling,
and it worked.  Thank you, Jacob.  It's very exciting. :-)

Best regards,
Rick C. Hodgin

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

#67480

Le 16/08/2015 00:05, Rick C. Hodgin a écrit :
> That is almost exactly what I have planned, except that my "compile()"
> function will have to parse Logician source code, converting it to a
> series of C function call-backs into Logician's main algorithms, along
> with the ability to be called with line number execution and single-
> step debugging abilities.

This is similar to another customer I have: an SQL database that 
translates SQL into a series of C statements that go into their database 
runtime.

I offer (of course) a debugger too.

All in all I could save you a LOT of work but you know, it is fun to do 
that.

The JIT project costed me a few years... It is tricky, do not 
underestimate the time needed.

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

#67526

On 16/08/15 00:12, jacobnavia wrote:
> Le 16/08/2015 00:05, Rick C. Hodgin a écrit :
>> That is almost exactly what I have planned, except that my "compile()"
>> function will have to parse Logician source code, converting it to a
>> series of C function call-backs into Logician's main algorithms, along
>> with the ability to be called with line number execution and single-
>> step debugging abilities.
>
> This is similar to another customer I have: an SQL database that
> translates SQL into a series of C statements that go into their database
> runtime.
>
> I offer (of course) a debugger too.
>
> All in all I could save you a LOT of work but you know, it is fun to do
> that.
>
> The JIT project costed me a few years... It is tricky, do not
> underestimate the time needed.
>
>

Just-in-time compilation is done in many ways and by many types of 
software.  Other examples are Pypy (Python, using llvm to compile code 
rather than interpret everything), BSD's network filter system (and 
Linux has recently gained a similar system), and of course many Java 
VM's do JIT compilation.  llvm was designed from the start to support 
JIT, but now even gcc is getting in on the act.

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

#67485

jacobnavia wrote:
> Le 15/08/2015 20:56, Rick C. Hodgin a écrit :
>> I'm having a dry spell today.  I feel like an artist sitting in front
>> of a canvas wanting to paint, but no inspiration is coming.:-)
>
> Look. I did that several years ago.
>
> 1) I wrote a software that can load an object file into memory and link
> it in the fly.
>
> 2) I wrote a JIT. Just pass it a buffer with C code.
>
> #include <jit.h>
>
> typedef 	void (*Function)(void);
> int main(void)
> {
>     Function sayHello = compile("int main(void){printf(\"Hello\\n\");}");
>     sayHello();
> }

How do you handle compilation errors?

-- 
Ian Collins

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

#67487

Le 16/08/2015 00:47, Ian Collins a écrit :
> How do you handle compilation errors?

Depends on customer specs.

1) Return an empty function that does nothing
2) Exit the whole system
3) Return NULL

Etc. It is as you want.

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

#67477

On Saturday, August 15, 2015 at 2:56:23 PM UTC-4, Rick C. Hodgin wrote:
> I can relate very strongly to Charlie in the TV show Numb3rs, Season
> 1, Episode 2, "Uncertainty Principle", beginning around 16 minutes in,
> when Charlie's telling Professor Fleinhardt and Don about how he can't
> turn his thinking on or off at times, and that he has to follow things
> thru where the inspiration leads him.  Around 19 minutes he says:
> 
>     "Please understand.  Sometimes I can't choose what I work on.
>      I can't follow thru on a line of thinking just because I want
>      to, or because it's needed.  I have to work on what's in my
>      head.  And right now, this is what's in my head."

You can see this scene here, from 16:00 thru 20:03:

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

> I feel like that on many things in my life, and many of these things
> I have come up with for Visual FreePro, for the LibSF 386-x40 CPU,
> for RDC, etc., they aren't my thoughts, meaning I didn't just think
> them thru.  Instead, they came to me as fully-formed inspiration,
> deposited in my thoughts without me having to consider it.  And this
> is a recurring theme for me, and something that always amazes me.
> The same thing happens in music, and in solutions to various things
> which come up in my life.  It's really quite something.  I am on an
> ongoing basis consistently amazed by how that process works, and I
> state to everybody:  "It's not me."  These are things being given
> to me, and I am running with them at each point where the inspiration
> strikes.
> 
> Does anybody else experience this in creativity in design?

Best regards,
Rick C. Hodgin

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

#67479

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> For my needs on this, I have realized that I probably could use DLLs.
> I'm reticent though because there may be an issue as I'll likely have
> thousands of separate DLLs loaded at one time on large projects, and
> that may be a significant burden on the operating system.  Perhaps
> not.

I don;t think there's anything that will tell you if your sus-
picions are for real but testing. Shouldn't be too much hassle
to create say 10000 small shared libraries (all the same, just
copies of one file but with different names) and trying to load
them all at once (one array for the DLL handles and one for the
function pointers). One thing that may put a wrench in the works
is if open libraries count into the number of files a program
may have open at the same time, though... 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?

> For now I think I'll stick with GCC and -fPIC creating one function
> at a time with all parameters passed in to access global variables,
> and callback functions, etc.  This will allow me to load-from-then-close
> the library file which has the program content, and then I'm just
> dealing with malloc() and free() for live changes.

How do you actually "copy" the functions? First question is
how do you determine their sizes? And the second snag I'd be
worried about is that typically you can't execute stuff in
"normal" (data) memory - on many modern systems you neither
can modify code in memory nor "run" code in normal heap me-
mory as obtained by malloc() (for obvious security reasons,
see e.g. https://en.wikipedia.org/wiki/NX_bit).

> -----
> I'm having a dry spell today.  I feel like an artist sitting in front
> of a canvas wanting to paint, but no inspiration is coming. :-)
> Happens to me sometimes.  Other times I can't shut it off, and it
> causes me stress in my life due to lack of sleep and what have you.

[SNIPPED]

> Does anybody else experience this in creativity in design?

And your C question was?;-) (And, yes, I guess everyone has
these times where nothing seems to work and others where all
seems to be easy and it's hard to keep up with typing at the
speed new ideas pop up, and where one wakes up too early in
the morning, knowing exactly the line were one made a mistake
and how to fix it and all that kind of stuff. Wouldn't be fun
otherwise;-)
                          Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#67481

Le 16/08/2015 00:09, Jens Thoms Toerring a écrit :
> How do you actually "copy" the functions?

There is no way to do that since all the "ad hoc" methods will fail. You 
can suppose that all functions start with the byte codes for

push rsp
move rbp, rsp

etc...

And that will work with a few examples.

Then you search for the sequence
leave
ret

But then you need a good disassembler to find out where the return is,
and a fast disassembler is difficult to write...

> First question is
> how do you determine their sizes?

No way...

> And the second snag I'd be
> worried about is that typically you can't execute stuff in
> "normal" (data) memory - on many modern systems you neither
> can modify code in memory nor "run" code in normal heap me-
> mory as obtained by malloc() (for obvious security reasons,
> see e.g.https://en.wikipedia.org/wiki/NX_bit).

That is one of the minor problems. You can solve it by reading the 
appropiate documentation.

But then how do you resolve the calls?

If function f() calls printf or something how do you find out where is 
printf in memory to fix that call?

Specially since all calls are RIP relative in the x86...

But Rick will find out all that himself. Slowly, as he goes on 
developing his project.

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

#67491

jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 16/08/2015 00:09, Jens Thoms Toerring a écrit :
> > How do you actually "copy" the functions?

> There is no way to do that since all the "ad hoc" methods will fail. You 
> can suppose that all functions start with the byte codes for

> push rsp
> move rbp, rsp

> etc...

> And that will work with a few examples.

> Then you search for the sequence
> leave
> ret

> But then you need a good disassembler to find out where the return is,
> and a fast disassembler is difficult to write...

On a certain architecture and possibly OS...

> > First question is
> > how do you determine their sizes?

> No way...

> > And the second snag I'd be
> > worried about is that typically you can't execute stuff in
> > "normal" (data) memory - on many modern systems you neither
> > can modify code in memory nor "run" code in normal heap me-
> > mory as obtained by malloc() (for obvious security reasons,
> > see e.g.https://en.wikipedia.org/wiki/NX_bit).

> That is one of the minor problems. You can solve it by reading the 
> appropiate documentation.

On a certain architecture and and a certain OS...

> But then how do you resolve the calls?

> If function f() calls printf or something how do you find out where is 
> printf in memory to fix that call?

> Specially since all calls are RIP relative in the x86...

Well, every call in the functions to something outside will
be "interesting" to deal with (once one has figured out where
that happens). Even if one wants to do that for only one
architecture one knows a lot about. I gues I'd prefer to
leave all that to the existing runtime loader I dont have
to write myself;-)
                         Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#67497

Le 16/08/2015 01:44, Jens Thoms Toerring a écrit :
>> That is one of the minor problems. You can solve it by reading the
>> >appropiate documentation.
> On a certain architecture and and a certain OS...
>

Well I found the docs under linux/windows/and mac.

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

#67499

Le 16/08/2015 02:25, jacobnavia a écrit :
> Le 16/08/2015 01:44, Jens Thoms Toerring a écrit :
>>> That is one of the minor problems. You can solve it by reading the
>>> >appropiate documentation.
>> On a certain architecture and and a certain OS...
>>
>
> Well I found the docs under linux/windows/and mac.

Forgot AIX (the RS6000 system)

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

#67501

jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 16/08/2015 01:44, Jens Thoms Toerring a écrit :
> >> That is one of the minor problems. You can solve it by reading the
> >> >appropiate documentation.
> > On a certain architecture and and a certain OS...

> Well I found the docs under linux/windows/and mac.

Well, I'm sure YOU would if it can be found at all;-) But
not everyone would even know what to look for...

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

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

#67482

On Saturday, August 15, 2015 at 6:09:55 PM UTC-4, Jens Thoms Toerring wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > For my needs on this, I have realized that I probably could use DLLs.
> > I'm reticent though because there may be an issue as I'll likely have
> > thousands of separate DLLs loaded at one time on large projects, and
> > that may be a significant burden on the operating system.  Perhaps
> > not.
> 
> I don;t think there's anything that will tell you if your sus-
> picions are for real but testing. Shouldn't be too much hassle
> to create say 10000 small shared libraries (all the same, just
> copies of one file but with different names) and trying to load
> them all at once (one array for the DLL handles and one for the
> function pointers). One thing that may put a wrench in the works
> is if open libraries count into the number of files a program
> may have open at the same time, though... 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:


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


There will need to be all of the algorithms (most likely each of them
will be less than 10 KB compiled) all loaded at the same time because
hardware is essentially a massively parallel series of executions, and
in order for me to emulate both clock-based synchronous, and clockless
asynchronous hardware, it will have to be able to issue a series of
logical phases (8 for clocked circuits, and I'm not completely sure
yet for asynchronous, though I'm thinking 4 right now).

> > For now I think I'll stick with GCC and -fPIC creating one function
> > at a time with all parameters passed in to access global variables,
> > and callback functions, etc.  This will allow me to load-from-then-close
> > the library file which has the program content, and then I'm just
> > dealing with malloc() and free() for live changes.
> 
> How do you actually "copy" the functions? First question is
> how do you determine their sizes?

When I compile I'll have it generate a .map file. The map will tell me.

> And the second snag I'd be
> worried about is that typically you can't execute stuff in
> "normal" (data) memory - on many modern systems you neither
> can modify code in memory nor "run" code in normal heap me-
> mory as obtained by malloc() (for obvious security reasons,
> see e.g. https://en.wikipedia.org/wiki/NX_bit).

We'll see.  I'll be working on it here in a couple hours (Lord willing).

Best regards,
Rick C. Hodgin

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

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

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

csiph-web