a way to configure LLDB with script support?
I think you need to use the ports lldb.
--
Rui Paulo
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
from
> /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:69:
> /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/sys/malloc.h:177:6: note:
> previous declaration of 'free' was here
> void free(void *addr,
r decided to inline a few functions.
Unfortunately, I never saw any difference between -Os and -O2 in all of my
tests (boot2 and other code).
--
Rui Paulo
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
rpaulo accepted this revision.
rpaulo added a reviewer: rpaulo.
REVISION DETAIL
https://reviews.freebsd.org/D2156
To: emaste, imp, bapt, rpaulo
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
rpaulo added a subscriber: rpaulo.
rpaulo added a comment.
How is install(1) executed? What controls "stripping" via install(1) is the
STRIP make variable, so if I set that to null, won't that also avoid stripping
crunched binaries? Is that expected?
REVISION DETAIL
https://reviews.freebsd.
rpaulo accepted this revision.
rpaulo added a comment.
I agree with kib that this deserves a comment. And perhaps add another comment
in D1819 explaining why it isn't needed for .rel relocations.
REVISION DETAIL
https://reviews.freebsd.org/D1826
To: emaste, kostikbel, rpaulo
Cc: freebsd-tool
rpaulo added a subscriber: rpaulo.
rpaulo accepted this revision.
rpaulo added a reviewer: rpaulo.
rpaulo added a comment.
This revision is now accepted and ready to land.
Reviewed.
REVISION DETAIL
https://reviews.freebsd.org/D1819
To: emaste, gnn, rpaulo
Cc: rpaulo, freebsd-toolchain
rpaulo accepted this revision.
rpaulo added a reviewer: rpaulo.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1682
To: emaste, rpaulo
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
rpaulo added a comment.
>>! In D1428#5, @emaste wrote:
>>>! In D1428#3, @rpaulo wrote:
>> This looks odd. Why are we relying on magic numbers instead of
>> constants/enums like before?
>
> Some of the constants in the previous version are Linux-specific, and don't
> exist in our ELF headers.
>
rpaulo added a subscriber: rpaulo.
rpaulo added a comment.
This looks odd. Why are we relying on magic numbers instead of constants/enums
like before?
REVISION DETAIL
https://reviews.freebsd.org/D1428
To: emaste
Cc: rpaulo, freebsd-toolchain
___
fr
On Sep 21, 2014, at 18:48, Steve Kargl
wrote:
> On Sun, Sep 21, 2014 at 06:38:48PM -0700, Rui Paulo wrote:
>> On Sep 21, 2014, at 18:19, Steve Kargl
>> wrote:
>>>
>>> #include
>>> #include
>>>
>>> int
>>> main(vo
On Sep 21, 2014, at 18:38, Rui Paulo wrote:
> On Sep 21, 2014, at 18:19, Steve Kargl
> wrote:
>>
>> #include
>> #include
>>
>> int
>> main(void)
>> {
>> uint16_t i;
>> i = 0x3ff0+63; printf("%x\n", i);
>>
i = 0x3ff8+63; printf("%x\n", i);
> i = 0x3ff9+63; printf("%x\n", i);
> i = 0x3ffa+63; printf("%x\n", i);
> i = 0x3ffb+63; printf("%x\n", i);
> i = 0x3ffc+63; printf("%x\n", i);
> i = 0x3ffd
On Jun 9, 2014, at 19:44, Ed Maste wrote:
> I had the same issue in LLVM, and as hacky as it seems, the solution
> is to check that the name starts with "_Z" before passing it to
> __cxa_demangle.
This is what I also did for lib
LGPL libdwarf. Given the push to keep the tree
mostly BSD licenced, I would say the former.
--
Rui Paulo
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to &q
On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote:
> On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote:
>
>> On 24 Aug 2013, at 16:06, Steve Kargl
>> wrote:
>>
>>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
>>>>
ild error log.
>>
>> Please file clang bugs at http://llvm.org/bugs/
>>
>
> As if this is going to help.
>
> http://llvm.org/bugs/show_bug.cgi?id=8532
>
> 2 years, 9 month and counting.
Irrelevant to the dis
individuals pushing the
> change to clang actually tests clang on floating point
> intensive applications, it is IMHO dubious to even have
> clang as the default compiler. Just the latest example:
>
> http://lists.freebsd.org/pipermail/f
on the general direction of this work. We switched to Clang as
the default compiler for i386/amd64 some months ago and now you're working on
improving our base GCC especially for amd64? I don't really understand how
useful this is. It doesn't strike me as a good idea to see people wor
On Nov 6, 2011, at 4:36 PM, Warner Losh wrote:
> On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote:
>> The only argument against this tautological check that I agree with is when
>> the code is explicitly trying to be safe. If the developer checks for "i <
>> 0"
ng to be safe. If the developer checks for "i < 0" when
indexing an array he/she is trying to guard against possible pitfalls in the
future when someone suddenly decides to change the variable type to become
signed. One possible security vulnerability was avoi
21 matches
Mail list logo
