I've not implemented this yet because there are a couple of TODO remarks
in the code (and question marks), and you speak about only testing this
briefly.
How stable is this code ?
Also (see the recent mail from Nic Roets) do you have experience mapping
large files with this code ?
Danny
I believe I've seen reports before about our version of gdb and 64-bit
systems.
It may be a better idea to try and use the latest gdb from the GNU
website. As you may have seen from recent posts, it works out of the box
with cegcc, so I think we should remove the old gdb from the cegcc
source tree
Cc-ing the list.
Nick, you should be able to post once you subscribe to the list.
This looks like the same problem that Jérôme Decoodt is experiencing :
> Good news!
>
> Jerome Decoodt found a workaround to get applications working on
> Windows
> Mobile 6.1.
> It seems that you can ask system n
Hi,
ok, talking to myself here...
It seems that the problem is that the symbol is redefined
incompatibly. It's bound to get redefined, as gdb sources include both
core windows headers and core native platform headers. Since I'm
building on x86_64, the size_t is defined 64 bit in platform headers,
I'm trying to compile gdb from the SVN sources, and am miserably failing there.
Any suggestions as to what I might be doing wrong, or what's wrong with my
box? It seems that that particular file is supposed to be compiled for the host
architecture, but it picks up the linux stdarg.h and windows inc
My program maps a file into memory using the code below. Being a 32 bit
architecture I expected to be able to map files of close to 2GB. I am
however only able to map files of around 410MB. Has anyone any experience in
mapping files of this size and larger ?
HANDLE gmap = CreateFileForMapping (f
