Re: [PATCH v2] Make '{add-,}symbol-file' not care about the position of command line arguments

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Thursday, November 30 2017, Pedro Alves wrote:

>>> Does this push_back directly here mean that these
>>> two commands end up with different semantics?
>>>
>>>  (gdb) add-symbol-file FILE 0 -s .text 0x1000
>>>  (gdb) add-symbol-file -s .text 0x1000 FILE 0
>> 
>> The arguments are printed in a different order, yes:
>> 
>> (gdb) add-symbol-file -s .text 0x100 ./gdb/testsuite/outputs/gdb.base/relocate/relocate.o 0
>> add symbol table from file "./gdb/testsuite/outputs/gdb.base/relocate/relocate.o" at
>>         .text_addr = 0x100
>>         .text_addr = 0x0
>> (y or n) n
>> Not confirmed.
>> (gdb) add-symbol-file  ./gdb/testsuite/outputs/gdb.base/relocate/relocate.o 0 -s .text 0x100
>> add symbol table from file "./gdb/testsuite/outputs/gdb.base/relocate/relocate.o" at
>>         .text_addr = 0x0
>>         .text_addr = 0x100
>> (y or n) n
>> Not confirmed.
>> 
>>> Not sure that's a good idea.
>> 
>> I'll work on it and make sure they're always printed in the same way.
>
> TBC, the worry was not really about the printing (that's minor),
> but what is the actual resulting .text address that the symbol file
> it loaded at in the end.  But sounds like the printing order can
> be used as proxy for checking that.  It's not as robust as
> actually loading the symbols and then checking what happened
> (with e.g., printing a symbol's address), but it's good
> enough.

Right, I got it.

The way I made it now, the address provided as .text will always be the
first to be set/printed, even if the user provides a "-s .text" later.
This maintains compatibility with the current way of doing things.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/