optind

optind

[Baurjan Ismagulov]

Hello,

given the following program:

#include <unistd.h>

int main()
{
	printf("%p\n", &optind);
}


I do:

gcc -g a.c
./a.out
nm a.out |grep optind


I see, respectively:

0x80495ac
080495ac B optind@@GLIBC_2.0


After that I do:

gdb a.out
b main
r
p &optind


I see:

$1 = (int *) 0x4014814c,

whereas I expect it to be 080495ac. Naturally, "p optind" displays
another value, too. What is going on?


Thanks in advance,
Baurjan.

Re: optind

[Daniel Jacobowitz]

On Wed, Dec 10, 2003 at 04:20:47PM +0200, Baurjan Ismagulov wrote:
> Hello,
> 
> given the following program:
> 
> #include <unistd.h>
> 
> int main()
> {
> 	printf("%p\n", &optind);
> }
> 
> 
> I do:
> 
> gcc -g a.c
> ./a.out
> nm a.out |grep optind
> 
> 
> I see, respectively:
> 
> 0x80495ac
> 080495ac B optind@@GLIBC_2.0
> 
> 
> After that I do:
> 
> gdb a.out
> b main
> r
> p &optind
> 
> 
> I see:
> 
> $1 = (int *) 0x4014814c,
> 
> whereas I expect it to be 080495ac. Naturally, "p optind" displays
> another value, too. What is going on?

The symbol exists in multiple shared objects, and gdb gets confused
about which copy to print.  We can't get this right all the time, but I
would have thought we'd get this one right; might want to file a bug
report.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: optind

[Baurjan Ismagulov]

Hello, Daniel!

That was fast 8) , thanks much!

On Wed, Dec 10, 2003 at 09:49:18AM -0500, Daniel Jacobowitz wrote:
> The symbol exists in multiple shared objects...

Do you mean weak symbols within libc, or multiple definitions in other
libraries? ldd shows libc.so.6 and ld-linux.so.2, and nm -D shows that
optind exists only in libc. I've also searched glibc 2.3.2 sources and
couldn't find multiple optind definitions. Where do you think they are
defined?


> ... and gdb gets confused about which copy to print.

I thought they were resolved during link, and the resulting binary had
only one copy. From what you have said I understand the following: each
copy declared in different objects gets linked and is preserved in the
data section(s), all references to it are set to one address chosen as
"main" one, and there is no way to find out which one this "main" is.
Is this right?


FWIW, I've also tested with gdb 6.0, the result was the same.


With kind regards,
Baurjan.

Re: optind

[Andreas Schwab]

Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr> writes:

> Hello, Daniel!
>
> That was fast 8) , thanks much!
>
> On Wed, Dec 10, 2003 at 09:49:18AM -0500, Daniel Jacobowitz wrote:
>> The symbol exists in multiple shared objects...
>
> Do you mean weak symbols within libc, or multiple definitions in other
> libraries? ldd shows libc.so.6 and ld-linux.so.2, and nm -D shows that
> optind exists only in libc.

It also exists in the executable, due to a COPY relocation.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: optind

[Baurjan Ismagulov]

Hello, Andreas!

On Wed, Dec 10, 2003 at 05:12:56PM +0100, Andreas Schwab wrote:
> It also exists in the executable, due to a COPY relocation.

Thanks much, I see it now!

And how should gdb know which one to use?

With kind regards,
Baurjan.

Re: optind

[Ian Lance Taylor]

Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr> writes:

> On Wed, Dec 10, 2003 at 05:12:56PM +0100, Andreas Schwab wrote:
> > It also exists in the executable, due to a COPY relocation.
> 
> Thanks much, I see it now!
> 
> And how should gdb know which one to use?

gdb should always use the one in the executable.  That is the one the
code in the shared library will also be using, because that is the
address will be in the GOT.

In principle, while debugging shared library code, gdb could observe
that there is a GOT relocation for optind, and look at the GOT table
in memory to decide which address to use.

Alternatively, gdb could guess that if there is a global variable in
the executable, that any reference to that global variable in the
shared library will refer to the one in the executable.  This will
normally be true, but will fail in cases where the library is
controlling visibility in any of various different ways.

In practice I have no idea what gdb actually does.

Ian

Re: optind

[Daniel Jacobowitz]

On Wed, Dec 10, 2003 at 12:04:22PM -0500, Ian Lance Taylor wrote:
> Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr> writes:
> 
> > On Wed, Dec 10, 2003 at 05:12:56PM +0100, Andreas Schwab wrote:
> > > It also exists in the executable, due to a COPY relocation.
> > 
> > Thanks much, I see it now!
> > 
> > And how should gdb know which one to use?
> 
> gdb should always use the one in the executable.  That is the one the
> code in the shared library will also be using, because that is the
> address will be in the GOT.
> 
> In principle, while debugging shared library code, gdb could observe
> that there is a GOT relocation for optind, and look at the GOT table
> in memory to decide which address to use.
> 
> Alternatively, gdb could guess that if there is a global variable in
> the executable, that any reference to that global variable in the
> shared library will refer to the one in the executable.  This will
> normally be true, but will fail in cases where the library is
> controlling visibility in any of various different ways.

For global variables the sensible default is to use the one in the
executable.  This gets much more fun, of course, for function
addresses.

> In practice I have no idea what gdb actually does.

Neither does GDB.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: optind

[Baurjan Ismagulov]

Hello, Daniel and Ian!

On Wed, Dec 10, 2003 at 12:17:15PM -0500, Daniel Jacobowitz wrote:
> > This will
> > normally be true, but will fail in cases where the library is
> > controlling visibility in any of various different ways.
> For global variables the sensible default is to use the one in the
> executable.  This gets much more fun, of course, for function
> addresses.

Could you please enlighten me regarding the following, too:

1. How can the visibility of a symbol be controlled by the library?

2. Why does this get much more fun for function addresses?

Thanks in advance,
Baurjan.

Re: optind

[Daniel Jacobowitz]

On Wed, Dec 10, 2003 at 07:37:32PM +0200, Baurjan Ismagulov wrote:
> Hello, Daniel and Ian!
> 
> On Wed, Dec 10, 2003 at 12:17:15PM -0500, Daniel Jacobowitz wrote:
> > > This will
> > > normally be true, but will fail in cases where the library is
> > > controlling visibility in any of various different ways.
> > For global variables the sensible default is to use the one in the
> > executable.  This gets much more fun, of course, for function
> > addresses.
> 
> Could you please enlighten me regarding the following, too:
> 
> 1. How can the visibility of a symbol be controlled by the library?

Look of visibility in the GNU ld manual.

> 2. Why does this get much more fun for function addresses?

Because the rules on resolving symbols are much more general than the
case of copy relocations, which is quite simple.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: optind

[Baurjan Ismagulov]

Hello, Daniel!

On Thu, Dec 11, 2003 at 09:10:08AM -0500, Daniel Jacobowitz wrote:
> > 1. How can the visibility of a symbol be controlled by the library?
> Look of visibility in the GNU ld manual.

Ok.


> > 2. Why does this get much more fun for function addresses?
> Because the rules on resolving symbols are much more general than the
> case of copy relocations, which is quite simple.

But this is not related to fixing this particular copy relocation
resolution problem in gdb, or do I understand it wrongly?


Going to file the bug and read some sources...


With kind regards,
Baurjan.