On 25.07.2022 17:45, ibuc...@gdcproject.org wrote:
>> On 25/07/2022 14:13 CEST Jan Beulich wrote:
>>
>>
>> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
On 25/07/2022 08:45 CEST Jan Beulich wrote:
while commit 3f30a274913b ("libiberty: Update D symbol demangling
for latest A
> On 25/07/2022 14:13 CEST Jan Beulich wrote:
>
>
> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
> >> On 25/07/2022 08:45 CEST Jan Beulich wrote:
> >> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> >> for latest ABI spec") mentions in its description that tuple encod
On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
>> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>> while commit 3f30a274913b ("libiberty: Update D symbol demangling
>> for latest ABI spec") mentions in its description that tuple encoding
>> has changed, there's no real adjustment to dlang_parse_
> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>
>
> Hello,
>
> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> for latest ABI spec") mentions in its description that tuple encoding
> has changed, there's no real adjustment to dlang_parse_tuple() there,
> nor are there any n
On Fri, Jul 29, 2016 at 1:44 PM, Joseph Myers wrote:
> On Fri, 29 Jul 2016, Manuel López-Ibáñez wrote:
>
>> On 29 July 2016 at 16:25, Jeff Law wrote:
>> >> Well, if libiberty is going to be replaced en masse by gnulib, then
>> >> there's no sense in me cleaning up libiberty's regex.
>>
>> libiber
On Fri, 29 Jul 2016, Manuel López-Ibáñez wrote:
> On 29 July 2016 at 16:25, Jeff Law wrote:
> >> Well, if libiberty is going to be replaced en masse by gnulib, then
> >> there's no sense in me cleaning up libiberty's regex.
>
> libiberty cannot be replaced completely, because there are bits that
On 29 July 2016 at 16:25, Jeff Law wrote:
>> Well, if libiberty is going to be replaced en masse by gnulib, then
>> there's no sense in me cleaning up libiberty's regex.
libiberty cannot be replaced completely, because there are bits that
do not even exist in gnulib. And given the time frame, I d
On 07/29/2016 05:34 AM, Aldy Hernandez wrote:
On 07/29/2016 07:30 AM, Aldy Hernandez wrote:
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
res
On 07/29/2016 05:30 AM, Aldy Hernandez wrote:
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could prove painful
On Fri, 29 Jul 2016, Aldy Hernandez wrote:
> BTW, does this libiberty replacement project also fix binutils and gdb, or
> will these other libiberty users require independent patches for their
> respective projects?
GDB is already making extensive use of gnulib (I don't know to what extent
it st
On 07/29/2016 07:30 AM, Aldy Hernandez wrote:
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could prove painful
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could prove painful after 15 years of
divergence.
The current gl
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to resync
with glibc, though that could prove painful after 15 years of divergence.
The current glibc implementation is completely different; the libi
On Mon, 25 Jul 2016, Jeff Law wrote:
> I'll pre-approve removing those bits. Alternately, you could look to resync
> with glibc, though that could prove painful after 15 years of divergence.
The current glibc implementation is completely different; the libiberty
version was replaced in glibc ma
On 07/23/2016 04:33 AM, Aldy Hernandez wrote:
Hi guys!
I'm looking at libiberty's use of alloca() and trying to place some
bounded checks at alloca() call points.
Silly question, do we have any users of regex.c with REGEX_MALLOC set? I
don't see any #define for REGEX_MALLOC anywhere in binutils
On 07/23/2016 06:33 AM, Aldy Hernandez wrote:
If the REGEX_MALLOC mode in regex.c is unused, can I rip it out? I'd
like to replace it all with alloca with a malloc fallback.
And yes, I realize regex.c already does this most of the time:
if (size1 > MAX_ALLOCA_SIZE)
{
On Wednesday, January 05, 2011 11:44:58 Mike Frysinger wrote:
> On Tuesday, January 04, 2011 13:03:59 H.J. Lu wrote:
> > libiberty/.gitignore was added to src. But it isn't in gcc tree.
>
> i dont have access to the gcc tree, so i can only post patches. if someone
> were to grant me access, i obv
On Tuesday, January 04, 2011 13:03:59 H.J. Lu wrote:
> libiberty/.gitignore was added to src. But it isn't in gcc tree.
i dont have access to the gcc tree, so i can only post patches. if someone
were to grant me access, i obviously wouldnt have a problem making the commit.
otherwise someone el
Ralf Wildenhues wrote:
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
While Ralf's point about static data is valid, the functions likely to
be in libiberty on any platform supporting plugins should not suffer
from this problem.
Solaris 9 and IRIX 6.5 support dlopen
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
> While Ralf's point about static data is valid, the functions likely to
> be in libiberty on any platform supporting plugins should not suffer
> from this problem.
Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as mi
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote:
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote:
> Daniel Jacobowitz wrote:
> >On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
> >>In simpler words, *.so have to be compiled with -fPIC, and libiberty
> >>is not compiled with -fPIC.
> >
> >We build a PIC li
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with -fPIC.
We build a PIC libiberty already.
Thanks!
Where and how is it built? I cannot find any
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
> In simpler words, *.so have to be compiled with -fPIC, and libiberty
> is not compiled with -fPIC.
We build a PIC libiberty already.
While Ralf's point about static data is valid, the functions likely to
be in libiberty on an
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 02:50:04PM CEST:
> On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
> > But it seems to me that a plugin can call a libliberty function only if that
> > function is already referenced (e.g. called) from cc1. This is not the case
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
But it seems to me that a plugin can call a libliberty function only if that
function is already referenced (e.g. called) from cc1. This is not the case
of all libiberty functions.
So... link
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
> But it seems to me that a plugin can call a libliberty function only if that
> function is already referenced (e.g. called) from cc1. This is not the case
> of all libiberty functions.
So... link libiberty into your plugin and
Dave Korn wrote:
Basile STARYNKEVITCH wrote:
Dave Korn wrote:
We might also artificially add a reference to each libiberty function
from
cc1.
Or link it into cc1 et al. using "--whole-archive".
Sorry, I am not aware of this option. And are we sure it works o
Basile STARYNKEVITCH wrote:
> Dave Korn wrote:
>>
>>> We might also artificially add a reference to each libiberty function
>>> from
>>> cc1.
>>
>> Or link it into cc1 et al. using "--whole-archive".
>>
>>
> Sorry, I am not aware of this option. And are we sure it works on all
> the syste
Dave Korn wrote:
We might also artificially add a reference to each libiberty function from
cc1.
Or link it into cc1 et al. using "--whole-archive".
Sorry, I am not aware of this option. And are we sure it works on all
the systems GCC is supposed to run on?
If we did link dynami
Basile Starynkevitch wrote:
> Hello All,
>
> Perhaps libiberty should be a shared library, not a static one, linked from
> cc1, when GCC has plugin enabled.
> We might also artificially add a reference to each libiberty function from
> cc1.
Or link it into cc1 et al. using "--whole-archive".
Eli Zaretskii writes:
> 2009-04-14 Eli Zaretskii
>
> * configure.ac (setobjs, msdosdjgpp): Move a-priori setting of
> existing and required library functions to with_target_subdir
> section, so that the native build does detect them at configure
> time.
This is OK.
T
On Mon, 23 Feb 2009, Paolo Bonzini wrote:
> Jack Howarth wrote:
> > The same issue in the libiberty testsuite run can be seen with
> > the Apple regress server log at
> > http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip.
> > If you search for test-demangle, you will find...
>
> I'm sur
Jack Howarth wrote:
> The same issue in the libiberty testsuite run can be seen with
> the Apple regress server log at
> http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip.
> If you search for test-demangle, you will find...
I'm sure there is a bugzilla entry for that.
Paolo
The same issue in the libiberty testsuite run can be seen with
the Apple regress server log at
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip.
If you search for test-demangle, you will find...
+ make -j2 -k check
autogen -T /Users/regress/tbox/svn-gcc/fixincludes/check.tpl
/Users/re
IIRC, that whole clause was because cygwin's dll itself linked with
libiberty, so the auto-detect stuff needed an override to make sure
the right files were there when you build cygwin1.dll. Otherwise, it
would detect that cygwin had strsignal, not build it, then fail later
when cygwin1.dll could
On 10 December 2007 20:01, Brian Dessent wrote:
> Andreas Schwab wrote:
>
>> Typically in a multithreaded environment vfork is mapped to fork anyway.
>
> ...which is what I don't understand about this whole thread. It seems
> Dave is seeing some strange behavior in Cygwin, but Cygwin's vfork =
On Mon, Dec 10, 2007 at 11:35:15PM +0100, Andreas Schwab wrote:
> Glibc will map vfork to fork in a multithreaded environment.
LinuxThreads used to. NPTL does not; this caused various trouble for
GDB at the time.
--
Daniel Jacobowitz
CodeSourcery
Joe Buck <[EMAIL PROTECTED]> writes:
> While the standard's wording might need fixing, with every implementation
> of vfork I know of, there are no threads. It's a mechanism for systems
> that don't support fork (or that can only do fork in a horribly
> inefficient way, say because there's no MMU
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
>> While the standard's wording might need fixing, with every implementation
>> of vfork I know of, there are no threads. It's a mechanism for systems
>> that don't support fork (or that can
Joe Buck <[EMAIL PROTECTED]> writes:
> I don't think it's wise to waste time fixing theoretical bugs
> exposed by close reading of the standard. Now, messing with environ
> with vfork will mess up the parent process, and if that happens it's a
> bug. But getting around it by using fork will harm
On Mon, Dec 10, 2007 at 02:22:45PM -0500, Daniel Jacobowitz wrote:
> On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
> > While the standard's wording might need fixing, with every implementation
> > of vfork I know of, there are no threads. It's a mechanism for systems
> > that don't sup
Andreas Schwab wrote:
> Typically in a multithreaded environment vfork is mapped to fork anyway.
...which is what I don't understand about this whole thread. It seems
Dave is seeing some strange behavior in Cygwin, but Cygwin's vfork =
fork, there is no difference. There used to be a vfork spec
"Dave Korn" <[EMAIL PROTECTED]> writes:
> On 07 December 2007 20:52, Andreas Schwab wrote:
>
>> "Dave Korn" <[EMAIL PROTECTED]> writes:
>>
>>> Perhaps we could work around this case by setting environ in the parent
>>> before the vfork call and restoring it afterward, but we'd need kind of
>>>
On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
> While the standard's wording might need fixing, with every implementation
> of vfork I know of, there are no threads. It's a mechanism for systems
> that don't support fork (or that can only do fork in a horribly
> inefficient way, say be
On Mon, Dec 10, 2007 at 06:32:08PM -, Dave Korn wrote:
> On 07 December 2007 20:52, Andreas Schwab wrote:
>
> > "Dave Korn" <[EMAIL PROTECTED]> writes:
> >
> >> Perhaps we could work around this case by setting environ in the parent
> >> before the vfork call and restoring it afterward, but
On 07 December 2007 20:52, Andreas Schwab wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> Perhaps we could work around this case by setting environ in the parent
>> before the vfork call and restoring it afterward, but we'd need kind of
>> serialisation there,
>
> Do we? vfork should bl
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
| > But random suggestions based on something you read in school are useless
|
| You're wrong. My suggestions are not based from school and are not useless.
| My suggestions are based from university, books, papers and internet
What is the difference?
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there,
Do we? vfork should block the parent until the child calls execve or
exit.
Andreas
Dave Korn writes:
> Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there, and I don't know how to do a critical section using
> pthreads/posix.
A simple solution would be to call for
On 2007/12/7, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 07 December 2007 18:09, J.C. Pizarro wrote:
>
> > You're wrong. My suggestions are not based from school and are not useless.
>
> Now /you're/ wrong: your suggestions *are* useless. You suggested using
> inter-process communications to try
"Dave Korn" <[EMAIL PROTECTED]> writes:
> > On the other hand, the setting of environ is very dubious and is
> > likely to break on real systems. The code should be changed to call
> > execve instead. Unfortunately there is no standard execvpe function.
> > Fortunately gcc never uses the variant
On 12/7/07 1:09 PM, J.C. Pizarro wrote:
Do you permit me a question for you?
"Are important the suggestions?"
J.C.Pizarro
JC,
The problem that many of us have with your responses is that they are
almost always content-free. You do not seem to grasp the basic
principles of the issue
On 07 December 2007 18:09, J.C. Pizarro wrote:
> You're wrong. My suggestions are not based from school and are not useless.
Now /you're/ wrong: your suggestions *are* useless. You suggested using
inter-process communications to try and resolve a potential data-access race
condition between mu
J.C. Pizarro writes:
> You're wrong. My suggestions are not based from school and are not useless.
> My suggestions are based from university, books, papers and internet, and
> i did put those by a same reason, my freedom.
You have the freedom to make useless postings to this list, just as we
2007/12/7, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 05:41:50PM -, Dave Korn wrote:
> > On 07 December 2007 17:24, J.C. Pizarro wrote:
> >
> > > You can do a critical section mainly between processes
> >
> > Thanks for your well-meaning attempt to help, but you don't under
On Fri, Dec 07, 2007 at 05:41:50PM -, Dave Korn wrote:
> On 07 December 2007 17:24, J.C. Pizarro wrote:
>
> > You can do a critical section mainly between processes
>
> Thanks for your well-meaning attempt to help, but you don't understand what
> we're talking about, and sending a generic
On 07 December 2007 17:24, J.C. Pizarro wrote:
> You can do a critical section mainly between processes
Thanks for your well-meaning attempt to help, but you don't understand what
we're talking about, and sending a generic list of synchronisation techniques
without regard to their relevance or
On 2007/12/07, "Dave Korn" <[EMAIL PROTECTED]> wrote:
> > On the other hand, the setting of environ is very dubious and is
> > likely to break on real systems. The code should be changed to call
> > execve instead. Unfortunately there is no standard execvpe function.
> > Fortunately gcc never use
On 07 December 2007 16:59, Ian Lance Taylor wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> Note the several calls to dup2() and close(), which seem to me to be
>> "calls [to] any other function", and the setting of environ, which seem to
>> me to be modification of "any data other than a
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Note the several calls to dup2() and close(), which seem to me to be "calls
> [to] any other function", and the setting of environ, which seem to me to be
> modification of "any data other than a variable of type pid_t used to store
> the return value fr
Thank you all for the excellent suggestions, I'll be looking into all
of your references this afternoon. Regarding my initial question, I
understand I don't need free.
My real problem was if I needed to include standard libraries after
including system.h or if system.h would provide me free from s
On 3/8/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Another convenient way of allocating a pool of memory is to use obstacks
(See libiberty/obstack.c).
Though alloc-pool might be a better idea than obstack, see
alloc-pool.[ch]. As alloc-pool contains checking code while obstack
does not.
-- P
Dave Korn wrote on 03/08/07 07:30:
> (Also, bear in mind that if you want your new pass to work correctly with
> pre-compiled headers, you really ought to be using Gcc's garbage-collected
> memory management facilities. See
> http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Infor
On 08 March 2007 11:46, Paulo J. Matos wrote:
> Hello all,
>
> when using functions from libiberty, I'm for example using xstrdup and
> xmalloc but free is not defined as free or xfree afail nor strlen so
> how should I include things? Before system.h and then standard libs or
> the other way aro
- Original Message -
From: "DJ Delorie" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 01, 2006 10:31 PM
Subject: Re: Libiberty
>
> Please don't reply to me personally, use the mailing list.
Sorry I just pressed reply. You pers
> I haven't found anything in the docs that I see that explains
> the libiberty library.
You didn't find the libiberty documentation? It's separate from the
gcc documentation, but available on the gcc docs web page.
> Can this be compiled without having to compile a whole new compiler?
Er,
On May 2, 2006, at 6:08 AM, Bill Cunningham wrote:
Everytime I compile gcc I see that libiberty is being compiled.
Is this
a needed library and if not how can I switch it off? I'm using
glibc-2.1 and
I'd like to figure out compiling 2.3 and I've done it before so I
just have
to remember
On 02 May 2006 14:09, Bill Cunningham wrote:
> Everytime I compile gcc I see that libiberty is being compiled. Is this
> a needed library
Yes. Gcc uses the support functions it provides. It's compiled and
statically linked in to the new gcc.
> I'm using glibc-2.1 and
> I'd like to figu
Mark Kettenis <[EMAIL PROTECTED]> writes:
>From: Ian Lance Taylor
>Date: 15 May 2005 23:20:14 -0400
>
>
>Well, we require an ISO C90 compiler; do we require ISO C90 libraries?
>If we require the libraries, then we can remove a number of files from
>libiberty, at least atexit
From: Ian Lance Taylor
Date: 15 May 2005 23:20:14 -0400
Well, we require an ISO C90 compiler; do we require ISO C90 libraries?
If we require the libraries, then we can remove a number of files from
libiberty, at least atexit.c, memchr.c, memcmp.c, memcpy.c, memmove.c,
memset.c,
Ian Lance Taylor writes:
[...]
| I think the more conservative approach would be to simply add strerror
| to AC_CHECK_DECLS, include in xstrerror.c (protected by
| HAVE_STRING_H), and protect the strerror declaration with
| #if !HAVE_DECL_STRERROR
Thanks, that indeed makes sense. Patch pe
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> The file libiberty/xstrerror.c contains the following fragment
>
> #ifdef VMS
> #include
> #if !defined (__STRICT_ANSI__) && !defined (__HIDE_FORBIDDEN_NAMES)
> extern char *strerror (int,...);
> #define DONT_DECLARE_STRERROR
>
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| On Sun, Apr 10, 2005 at 05:52:01PM +0200, Gabriel Dos Reis wrote:
| > Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| >
| > | On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote:
| > | >
| > | > Hi,
| > | >
| > | > The following is fr
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> The following is from libibtery.h
>
>/* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is
> undefined, we haven't run the autoconf check so provide the
> declaration without arguments. If it is 0, we checked and failed
On Sun, Apr 10, 2005 at 05:52:01PM +0200, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> | On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote:
> | >
> | > Hi,
> | >
> | > The following is from libibtery.h
> | >
> | >/* HAVE_DECL_* is a three-state
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote:
| >
| > Hi,
| >
| > The following is from libibtery.h
| >
| >/* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is
| > undefined, we haven't run the autoconf
On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote:
>
> Hi,
>
> The following is from libibtery.h
>
>/* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is
> undefined, we haven't run the autoconf check so provide the
> declaration without arguments. I
78 matches
Mail list logo
