Memory allocation with GR8NET and Fusion-C
Thank you for helpful answers!
Unfortunately avoiding 0x4000-0x7fff means I have less than 16Kb of memory for com file. I could probably fit my com into 26Kb but there is no way to cut 10Kb out of it without sacrificing half of functionality. Also SDCC is putting global variables to the end of com file and they definitely go beyond 0x4000 in memory breaking UNAPI.
Can Nextor move loaded com file to extended RAM of the GR8NET and run it from that location?
It doesn't mean that... Note that the only restriction is that the memory area you pass to UNAPI functions can't be on that position, your code can use it fully, as once UNAPI function returns it will switch back the memory to your program segment.
There are several ways to accomplish that, I'm lazy, so I use the easier one:
In .h file:
//Where we will allocate memory for hget and other processes
#define HI_MEMBLOCK_START 0xC000
On the c file:
// Allocate memory for HGET on page 2 so it won't conflict with memory page swapping
if (hgetinit(HI_MEMBLOCK_START) != ERR_TCPIPUNAPI_OK)
Of course, that limits my program to about 48KB, but if you check the map after building your program, you can adjust that.
There are more elegant ways like this one:
__at 0x8000 unsigned char ucRcvDataMemory[]; //area to hold data sent to UNAPI, need to be in the 3rd 16K block
Not sure why I don't use it on every program I do, but that should also guarantee that variable to be allocated where you want, perhaps there was a sdcc bug somewhere with it, but it works most of the times just fine as well 
So, just remember, any memory address / variable you pass as parameter for those UNAPI calls MUST NOT BE ON PAGE 1 (considering 0 0000 to 3FFF and 1 4000 to 7FFF), you can have other variables and program information there AS LONG AS it is not passed as a parameter for UNAPI calls. 
I also had this issue for data for HTTP requests. In my case I was a bit lazy and made a glue layer that transfers the data via a small stack buffer and repeats this until the buffer is depleted. This makes sure it always works, although not the fasted. At least you can continue with your application.
Since you have it failing on the connect, then using a small stack buffer as an intermediate step should cause not so much harm performance wise.
(I see I am slow at typing a response, and we are all lazy people 
.... I did not find the solution that ducasp suggested here yet, I am also definitely going to use that fixed address definition)
@ducasp
Bingo!
__at 0x8000 struct DD d[10];
did fix the issue with UNAPI and now HTTP communication is rock solid!
I still see some corruption inside d[10] so perhaps 0x8000 is not an ideal location but at least it solved my biggest obstacle to move forward.
Thank you very much!
Quite possibly sdcc is not being smart enough and that structure is being placed over some function or other variable and thus why it is getting overwritten. Check after compiling if there is something else occupying a similar space. My advise would be, look at the map, and place it way far from the last position occupied... There is one problem with this approach, your executable probably will as large as the address you choose, so, you can move it one KB or two after the end of your program, so it will not inflate the file size too much... If you just define the memory like I showed before, at 0xC000 and then cast your structure pointer to it and use*d when parsing the structure (since you will declare it as a pointer), file size won't inflate and your variable will be far, far away from code, sdcc area for variables, etc... Not beauty, but easy to have it in a place you know will work and won't cause any nuisance. 
And there is always a possibility you have a bug in your code, of course 
