[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] rl_complete() issue due to function pointer compariso

From: Mike Frysinger
Subject: Re: [Bug-readline] rl_complete() issue due to function pointer comparisons and PLT trampolines
Date: Fri, 27 Mar 2015 19:19:56 -0400

On 27 Mar 2015 11:03, Chet Ramey wrote:
> On 3/27/15 10:44 AM, Ulf Magnusson wrote:
> > I noticed that rl_bind_key('\t', rl_complete) causes completion to
> > break even though rl_complete is already the default binding for '\t'.
> > As a trivial example, pressing TAB multiple times will not list all
> > the matches when doing
> > 
> >     rl_bind_key('\t', rl_complete);
> >     readline(">");
> > 
> > I think the issue is this comparison in complete.c:
> > 
> >     else if (rl_last_func == rl_complete && !completion_changed_buffer)
> > 
> > When libreadline.so.6 is loaded at startup, rl_complete in the client
> > refers to a dynamic library trampoline in the PLT that in turn calls
> > the "real" rl_complete. Within the library, rl_complete always refers
> > to the real function. Therefore, they do not compare equal.
> There's not a lot we can do about this; it's the fault of the dynamic
> linker.

pretty sure it's the other way around -- if it's a dynamic symbol that's 
supposed to be resolved, then gcc should be generating code that looks the 
symbol up via the GOT.  since gcc is generating code that doesn't do that, 
there's really nothing the ldso can do.

i guess post to gcc.gnu.org bugzilla and see what they have to say.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]