You can also use radare or radare2. But source level is not very well
supported, just addr2line.
On Apr 18, 2010, at 10:28 AM, grischka wrote:
Alexei wrote:
Which debuggers work with TCC executables? I mean source level
debugging.
Thanks
GDB (or any debugger that understands stabs) shou
wever as I tried to compile several projects, several fail due to
> > the limitation regarding variable length arrays. Are there already
> > solutions out there?
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Add-support-for-C99-VLA.
Le dimanche 18 avril 2010 22:38:20, Rob a écrit :
> >if (libprefix && (!strncmp(ext, ".so", 2))) {
> >size_t len = ext - filename - 3;
> >strncpy(libname, filename + 3, len);
> >*(libname + len) = '\0';
> >return 1;
> >}
> >
> > I also
> if (libprefix && (!strncmp(ext, ".so", 2))) {
> size_t len = ext - filename - 3;
> strncpy(libname, filename + 3, len);
> *(libname + len) = '\0';
> return 1;
> }
>
> I also wonder wether is strncmp is a good idea here as it could match .s
Thomas Preud'homme wrote:
"libname" should be const (because it is "input only").
You mean filename in that case, and libname for libname_to_filename I guess.
Yes.
*(--ext) = '\0';
strcpy(libname, filename);
*ext = '.';
That's ugly.
Ok, I changed to:
if (libprefix && (!
mobi phil wrote:
I see two solutions:
1.
* write a pair dynarray_insert for dynarray_add, and insert all what
comes with -L in the coresponding order
* write a pair tcc_insert_library_path, and call dynarray_insert
2.
* reset the dynarray before calling tcc_insert_library_path from parse_args
On Sunday 18 April 2010 21:45:38 Thomas Preud'homme wrote:
[SNIP]
>
> >*(--ext) = '\0';
> >strcpy(libname, filename);
> >*ext = '.';
> >
> > That's ugly.
>
> Ok, I changed to:
>
> if (libprefix && (!strncmp(ext, ".so", 2))) {
> size_t len = ext - filename - 3;
>
On Saturday 17 April 2010 22:59:55 grischka wrote:
> Thanks for your work. Some comments on the pushed patches:
>
> RoboTux wrote:
> > [P|8de9b7a] Correctly support all unary expression with sizeof
> > Unary expression can start with a parenthesis. Thus, the current test
> > to detect which sizeo
indeed shuld be easy... did not do it myself, as I do not know well the
"rules in the house"
this was my comment in my earlier email:
I have libXXX both in /usr/lib and in /mysys/usr/lib for development.
Unfortunately /usr/lib is added first, and cannot be changed, so any
subsequent -L will be
Le dimanche 18 avril 2010 20:29:13, mobi phil a écrit :
> Does others compilers really make -L override the search path for libraries
> ?
>
> > Because to me when I add a -L gcc is still able to load libc.so and all
> > the libraries this ld script links.
> >
> > But to answer your question, indee
Does others compilers really make -L override the search path for libraries
?
> Because to me when I add a -L gcc is still able to load libc.so and all the
> libraries this ld script links.
>
> But to answer your question, indeed this patch doesn't change this
> behavior.
>
>
sorry... it is about
On Sunday 18 April 2010 19:46:42 mobi phil wrote:
> Hello...
>
> >> > [P|47abdbd] Better handle ld scripts
> >> > * search file from INPUT and GROUP commands in the library path in
> >> > addition to the current directory
> >> > * handle libraries specified by -lfoo options
> >> > * Search lib in
On Sun, Apr 18, 2010 at 7:27 PM, Thomas Preud'homme wrote:
> Le dimanche 18 avril 2010 13:58:39, mobi phil a écrit :
> > Sorry to instist
> >
> > is there any way to do memory allocation on the stack? (please read my
> > email below)
> > I think there are very few features missing to cover do
Hello...
>
>> > [P|47abdbd] Better handle ld scripts
>> > * search file from INPUT and GROUP commands in the library path in
>> > addition to the current directory
>> > * handle libraries specified by -lfoo options
>> > * Search lib in GROUP command repeatedly
>>
>
>
I understand that this patch
Le dimanche 18 avril 2010 16:38:41, Daniel Glöckner a écrit :
> On Sun, Apr 18, 2010 at 03:56:03PM +0200, Thomas Preud'homme wrote:
> > I see in the configure that armel architectures (or arm EABI) are
> > recognized by uname -m being equal to armv4l. But aren't armv5tel,
> > armv6j and armv7a vali
Le dimanche 18 avril 2010 13:58:39, mobi phil a écrit :
> Sorry to instist
>
> is there any way to do memory allocation on the stack? (please read my
> email below)
> I think there are very few features missing to cover double of the C code
> out there that can be compiled with TCC... and one
On Sun, Apr 18, 2010 at 03:56:03PM +0200, Thomas Preud'homme wrote:
> I see in the configure that armel architectures (or arm EABI) are
> recognized by uname -m being equal to armv4l. But aren't armv5tel,
> armv6j and armv7a valid architectures as well?
Yes, anything since ARMv4 that is little end
Greetings,
I see in the configure that armel architectures (or arm EABI) are recognized by
uname -m being equal to armv4l. But aren't armv5tel, armv6j and armv7a valid
architectures as well?
Thomas Preud'homme
___
Tinycc-devel mailing list
Tinycc-de
Sorry to instist
is there any way to do memory allocation on the stack? (please read my
email below)
I think there are very few features missing to cover double of the C code
out there that can be compiled with TCC... and one of them is variable
length arrays on the stack...
On Tue, Apr 6,
Alexei wrote:
Which debuggers work with TCC executables? I mean source level debugging.
Thanks
GDB (or any debugger that understands stabs) should work.
However we have just global symbols (functions and variables) and line
number info. No stack variables and no type info. So, basic but bet
Forwarded to the mailing list.
--- grischka
Original Message
Subject: Re: [Tinycc-devel] Several patchs from Debian packaging
Date: Sun, 18 Apr 2010 06:40:47 +0200
From: RoboTux
Reply-To: robo...@celest.fr
To: grischka
References: <201004171452.32731.robo...@celest.fr> <4bca2
Which debuggers work with TCC executables? I mean source level debugging.
Thanks
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
22 matches
Mail list logo