[RFA] new set/show multiple-choice-auto-select commands (take 2)

[Markus Deuling]

Hi Joel,

Joel Brobecker schrieb:
> 
> Let me clarify the current semantics of multiple-choice-auto-select.
> The idea is that, if multiple-choice-auto-select is turned on, then
> some "auto-select" will happen. Otherwise, no auto-select, and thus
> a menu needs to be displayed in order for the expression to be
> disambiguated. Now, in terms of the command itself:
> 
>   1. set multiple-choice-auto-select off (default):
>      Auto-select is turned off, so the multiple-choice menu is
>      displayed, and the user must chose the ones he wants.
> 
>   2. set multiple-choice-auto-select all:
>      In that case, the auto-select will automatically choose the "all"
>      choice. If the "all" option is not available because you are expected
>      to choose 1 and only 1 choice, then an error is triggered.
> 
>   3. set multiple-choice-auto-select cancel:
>      In that case, the auto-select will automatically choose the "cancel"
>      option of the multiple-choice menu.
> 

I fully agree. For my patch it means:

1. set multiple-choice-auto-select off (default):
   If there is 0 || 1 symbol found, GDB follows the "normal" code path. If > 1 symbol is found
   the user choice is invoked

2. set multiple-choice-auto-select all:
   If there is > 1 symbol found all symbols found are automagically taken for e.g. breakpoints.

3. set multiple-choice-auto-select cancel:
   I think I'll ignore this. It makes no sense in that case. 

What do you think about it? Does it make sense?

The problem I saw and still see is the change of the default behaviour of GDB (and with that maybe the introduction
of a lot of FAILs in the teststuite). The user has no possibility to avoid the user choice if there are > 1 symbols.
For my understanding that would for example break MI in some cases, doesn't it? Maybe it has even more side-effects I don't see yet.
That was the reason for me to have that feature switched off by default. 

> I spent some time familiarizing myself with -Bsymbolic and the way
> you introduced handling of these duplicated symbol names. Although
> you and Daniel thought that it would be a good idea to treat these
> types of symbols differently from other ambiguous expressions,
> I don't quite understand why. But regardless of that fact, it seems
> that the semantics of what you'd like to do is different from what
> I am introducing, and that you should therefore have your own option.

I implemented this behavior originally for the Cell BE combined debugger. Cell BE has binaries consisting of
PowerPC- and SPU-code. If there is a symbol foo in both the PowerPC- and the SPU-part then GDB would always
resolve the foo symbol from PowerPC (main executable) file no matter if it stands in a "SPU thread" or not. 
GDB recognizes SPU binaries as shared libraries. 

ELF standard (v1.2) says about DT_SYMBOLIC (inserted by -Bsymbolic):

"This elementÂ’s presence in a shared object library alters the dynamic linkerÂ’s symbol
resolution algorithm for references within the library. Instead of starting a symbol
search with the executable file, the dynamic linker starts from the shared object itself. If
the shared object fails to supply the referenced symbol, the dynamic linker then
searches the executable file and other shared objects as usual."

So there are at least two types of shared libs showing the same lookup behaviour. This was the reason to implement
the combined debugger functionality using a new common framework (solib callbacks) and at the same time also implement
it for ELF libs. 


Regards,
Markus

-- 
  Markus Deuling
  GNU Toolchain for Linux on Cell BE
  deuling@de.ibm.com