Hi,
this may be a stupid question, really, but I couldn't find anything
about this online...
For the cegcc functionality, it seems that the header files define
way more functions than are implemented in the libraries.
There are no bugs or feature requests submitted for missing functions.
Is there
Hi,
Was looking at the _close_r() in
src/newlib/newlib/libc/sys/wince/io.c, at the top:
EnterCriticalSection(&critsect);
FDCHECK(fd);
FDCHECK() macro can return from the method if file handle is invalid,
and if it does, wouldn't that leave the lock, and cause deadlock for I/O
operations?
Th
Thanks,
Pawel.
P.S. The source file seems to be in DOS format, and there is no
svn:eol-style property set... Shouldn't it be? The patch therefore is
half in DOS format :) (generated using svn diff)
On Fri, Aug 29, 2008 at 11:04 AM, Danny Backx <[EMAIL PROTECTED]> wrote:
> On Thu,
On Fri, Aug 29, 2008 at 11:07 AM, Danny Backx <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-08-28 at 17:54 -0700, Pawel Veselov wrote:
[ skipped ]
>> For the cegcc functionality, it seems that the header files define
>> way more functions than are implemented in the libraries.
Hi,
this attached fix should take care of providing fsync()/fdatasync()
functionliaty. For now it's a straight call to FlushFileBuffers().
Thanks,
Pawel.
On Fri, Aug 29, 2008 at 11:07 AM, Danny Backx <[EMAIL PROTECTED]> wrote:
[ skipped ]
> If you have corrections/submissions of this kind, p
Hi,
sorry, needs to be included in, or symbol doesn't get
exported. Here is the updated diff.
On Fri, Aug 29, 2008 at 3:52 PM, Pawel Veselov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> this attached fix should take care of providing fsync()/fdatasync()
> functionliaty. For now
to commit this is a ChangeLog entry.
>
>Danny
>
> On Fri, 2008-08-29 at 13:34 -0700, Pawel Veselov wrote:
>> This attached patch should take care of the _close_r() problem. As you
>> suggested, I extended FD_CHECK to take 2 arguments.
>>
>> Regarding prote
Hi,
I was looking at sys directory in newlib libc, and it seems
that stuff like "io.h" doesn't really belong there. The headers
get exported into public include/sys directory, and io.h contains
definitions for internal functions, structures and defines that
shouldn't be exported.
I can provide a
Hi !
I'm really sorry, but I can't any meaningful source on how to
make tracing print what it suppose to print... I'm using 'ush' to execute
my binaries, I did 'setenv WCETRACE_DEBUGGER all' and
'setenv WCETRACE all' and nothing is coming out. The funny thing is that
all the utilities that came wi
t, length, MEM_DECOMMIT)) {
+errno = _winerr2errno(GetLastError());
+WCETRACE(WCE_MALLOC, "VirtualFree(): errno=%d, oserr=%d",
+errno, GetLastError());
+ return -1;
+}
+return 0;
+}
+
+if (UnmapViewOfFile(start)) {
On Wed, Sep 3, 2008 at 11:37 AM, Danny Backx <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-09-02 at 18:41 -0700, Pawel Veselov wrote:
>> Hi,
>>
>> I was looking at sys directory in newlib libc, and it seems
>> that stuff like "io.h" doesn't really belon
t our newlib expects ?
>
>Danny
>
> On Tue, 2008-09-02 at 23:03 -0700, Pawel Veselov wrote:
>> Hi !
>>
>> I'm really sorry, but I can't any meaningful source on how to
>> make tracing print what it suppose to print... I'm using 'ush&
Hi,
not sure what's up with that, but I'm having this problem with gdb 6.4
# /gdb/wince-stub.exe 169.254.2.2 /bin/php
shows the box that reads
"Couldn't get UP address of host system. Error 11001"
I think in the source code, the idea is that if the host is given, then it
should do gethostbyname,
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
m/errno.h come from the same kernel version 2.6.18,
but first one was quoted from 2.6.18-6-k7 on debian, and mine is
2.6.18-92.1.10.el5 on CentOS 5.1
Not sure what the proper course of actions there is for all that.
Thanks,
Pawel.
On Tue, Sep 9, 2008 at 12:17 PM, Pawel Veselov <[EMAIL PROT
egcc, so I think we should remove the old gdb from the cegcc
> source tree...
>
> Danny
>
> On Tue, 2008-09-09 at 13:42 -0700, Pawel Veselov wrote:
>> Hi,
>>
>> ok, talking to myself here...
>>
>> It seems that the problem is that the symbol is redefine
Hi,
I was looking at the libcwd... There is a XCEGetCurrentDirectoryA()
function. It picks the current directory, that is stored in wide
chars, determines its length (in wide chars), and then converts wide
chars to multibyte. Then the wide char length is used as a terminator
for the length of the
Hi,
I've been playing around with compiling PHP and such. With default
compilation flags, (O3 is it?) the Zend would just SIGSEGV at random
locations. O0 cleared all the problems. So, may be, switching to a
newer gcc has certain weight.
Thanks,
Pawel.
--
With best of best regards
Pawel S. Ves
, Sep 12, 2008 at 2:23 AM, Sébastien Lorquet <[EMAIL PROTECTED]> wrote:
> I believed multibyte strings were using UTF-8, is it true or not?
>
> 2008/9/11 Danny Backx <[EMAIL PROTECTED]>
>>
>> On Thu, 2008-09-11 at 11:25 -0700, Pawel Veselov wrote:
>> > Hi,
&g
reatefile.c cecreatefilemap.c ceregistry.c cecurrentdir.c ceprofile.c \
ceshared2.c ceremovedir.c cemisc.c
Index: src/newlib/ChangeLog.cegcc
===
--- src/newlib/ChangeLog.cegcc (revision 1172)
+++ src/newlib/ChangeLog.cegcc (working cop
Hi,
would it be interesting if I did the following changes to wcetrace facilities:
* replace WCETRACE with the define that first evaluates the current
level and only then calls the trace printout. This will prevent
arguments from being evaluated if the tracing is off for the specified
level.
* Pr
2008 at 9:53 PM, Danny Backx <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-09-12 at 15:29 -0700, Pawel Veselov wrote:
>> would it be interesting if I did the following changes to wcetrace
>> facilities:
>>
>> * replace WCETRACE with the define that first evaluates t
I get this every now and then on some "stuck" applications:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x8001b6ec in ?? ()
(gdb) where
#0 0x8001b6ec in ?? ()
(gdb) info threads
* 1 Thread 1154900630 0x8001b6ec in ?? ()
warning: Couldn't restore frame in current thread, at frame 0
0x
Argh, took me a find out what's going on. Will need some more time to
actually produce a fix. Discovered all that while testing the changes
to the tracer.
The application has a good chance crashing in prologue, if it's being
attached to an existing process group. I guess those are the reasons I
fo
Hi,
On Wed, Sep 17, 2008 at 7:46 PM, Pedro Alves <[EMAIL PROTECTED]> wrote:
> On Thursday 18 September 2008 02:56:47, Pawel Veselov wrote:
>> Argh, took me a find out what's going on. Will need some more time to
>> actually produce a fix. Discovered all that while tes
Hi,
could some one may be please run svn ps svn:eol-style native on all
text files in there? :) Kinda awkward having CRLF files for unix dev
platform :)
Thanks!
Pawel.
--
With best of best regards
Pawel S. Veselov
-
This
match shared.h
Thanks!
Pawel.
On Wed, Sep 17, 2008 at 6:56 PM, Pawel Veselov <[EMAIL PROTECTED]> wrote:
> Argh, took me a find out what's going on. Will need some more time to
> actually produce a fix. Discovered all that while testing the changes
> to the tracer.
>
And, the patch ! :)
On Thu, Sep 18, 2008 at 4:29 PM, Pawel Veselov <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm attaching the patch that allegedly takes care of these problems.
> The main changes are:
>
> - prevent initializing the environment variables from the s
);
>> +}
>> +
>> +
>> +return i;
> I don't see anything clearing *env, either here, of at the caller
> if this returns 0. You're calling free on this pointer
> unconditionally, which in that case, would be a dangling pointer.
I'll dou
> Comments below. Please excuse my nit-pickiness. :-)
>> --- newlib/libc/sys/wince/sys/shared.h (revision 1182)
>> +++ newlib/libc/sys/wince/sys/shared.h (working copy)
>> @@ -30,10 +30,14 @@
>>
>> _SHMBLK _shared_init(int pgid);
>> void_shared_dump(_SHMBLK shmblk);
>> -int_shared_get
Hi,
while looking through the cegcc project, I discovered a few issues
with the setenv() (_setenv_r) and getenv() (_getenv_r) functions:
1. In the beginning of the function, the pointer to the value string
is shifted if the string starts with '='. The comment says that is to
prevent values to sta
Hi,
Well, as I keep on munching on the internals of newlib, and debugging
the problems I'm having with my code, I've discovered another sad
issue that I don't quite know how to overcome. May be the new gcc will
fix this.
The problem is that the dwarf debugging tables don't match the stack
frame o
Hi,
also discovered watchpoints don't work. Not sure the kinda effort it'd
take to support them for that platform. Probably gdbserver doesn't
know how to handle those. The output is:
[EMAIL PROTECTED] ws]# /opt/mingw32ce/bin/arm-mingw32ce-gdb wct
GNU gdb 6.8
This GDB was configured as "--host=i68
Umm, how about using
# MAKEFLAGS="-j12" sh build-
and leaving the build scripts alone? :)
On Thu, Sep 25, 2008 at 7:09 AM, Vincent R. <[EMAIL PROTECTED]> wrote:
> It's really weird because it seems your read my mind.
> I was already using -j option for make but since I was a bit afraid of
> re
Hi,
Could we prefix calling "configure"s with this test:
test ${BASE_DIRECTORY}/newlib/configure -nt config.status && \
(for all the components)
So we it won't reconfigure every time one is doing an incremental build?
Thanks!
Pawel.
--
With best of best regards
Pawel S. Veselov
---
Hi,
here is the modified patch, hope I got everything :)
Thanks,
Pawel.
On Sat, Sep 20, 2008 at 3:27 PM, Pedro Alves <[EMAIL PROTECTED]> wrote:
> On Saturday 20 September 2008 22:37:40, Pawel Veselov wrote:
>>
[ skipped ]
Index: src/newlib/newlib/libc/sys/win
Hi,
This is [somewhat] off topic. I was wondering, does anybody know
whether there is a COFF analogue of libelf out there. I find traces of
"libcoff.h" or "libecoff.h" in various source trees, but nothing that
would suggest that there is a library that knows how to dissect COFF
data from a stream.
!
Pawel.
On Sun, Sep 14, 2008 at 12:38 PM, Pawel Veselov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> That will also mean that the functions will change, and if there were
> binaries compiled against the old library, and they used the WCETRACE
> functions, they won't work anymore until
On Mon, Oct 6, 2008 at 5:33 PM, Pedro Alves <[EMAIL PROTECTED]> wrote:
>
>
> On Tuesday 07 October 2008 00:49:05, Pawel Veselov wrote:
>> +#define TRACING(level) ((WCETRACE_DEBUGGER_GET() & level) || \
>
> Can you rename TRACING into something else no so generic, p
Here is an updated version.
Thanks!
Pawel.
On Mon, Oct 6, 2008 at 5:54 PM, Pedro Alves <[EMAIL PROTECTED]> wrote:
> A Tuesday 07 October 2008 01:43:57, Pawel Veselov escreveu:
>> On Mon, Oct 6, 2008 at 5:33 PM, Pedro Alves <[EMAIL PROTECTED]> wrote:
>> >
>&g
Hi,
so, umm, what help are you asking for? :)
The chktsk goes down the stack and probes every page to make sure its
accessible before it is actually overrun (I guess a costly measure to avoid
stack overflows). I found its source code here:
http://read.pudn.com/downloads63/sourcecode/embed/220997
0, STACK_SIZE);
> Print("After memset\n");
> more();
> Print("returning\n");
> }
>
> The application never writes "In deeper function" and stuff that should
> happen later. This means two stack allocations half the size also
gcc code may user more of the stack than whatever code that msvc produces, thus
dipping into the red zone more often. So far, I don't see how the 64k
limit of the
stack on the main thread can be avoided at all..
On Mon, Jun 8, 2009 at 5:33 PM, Johnny Willemsen wrote:
>
> Hi,
>
> I have compiled t
Should the prologue code be rewritten to have
a thread created before main() is called?
Also, it'd be interesting to see where are the
new thread stacks are created, I've looked
at how other OSes do that, and they just
simply create a new segment. Since m$ seem
to not give you stack segment for th
tart, 0);
pthread_join(t1, &n);
pthread_join(t2, &n);
return 0;
}
On Tue, Jun 9, 2009 at 3:06 AM, Danny Backx wrote:
> You probably mean something like the attached test. What do you want to
> know about it ? I can run it on x86 and on ARM.
>
> Danny
>
.
>
> Danny
>
>
> On Tue, 2009-06-09 at 12:24 +0900, Pawel Veselov wrote:
>> I mean, something like this, but with Windows thread calls.
>> (I can't run any cegcc code at the moment).
>> Just wondering where would the stack addresses be for new
>> th
I would do that:
[...@e03077]/tmp$ cat > /tmp/1.c
#include
_CTYPE_Q
[...@e03077]/tmp$ gcc -E /tmp/1.c |tail
{snip}
0x0020L
[...@e03077]/tmp$
On Thu, Jun 11, 2009 at 5:10 PM, Sébastien Lorquet wrote:
> for my information, is the following an acceptable way to find unknown
> constant values?
>
hu, Jun 11, 2009 at 7:03 PM, Vincent R. wrote:
> On Thu, 11 Jun 2009 17:15:40 +0900, Pawel Veselov
> wrote:
>> I would do that:
>>
>> [...@e03077]/tmp$ cat > /tmp/1.c
>> #include
>> _CTYPE_Q
>> [...@e03077]/tmp$ gcc -E /tmp/1.c |tail
>> {snip}
>
48 matches
Mail list logo
