RE: [PATCH 0/3] remove-symbol-file

["Blanc, Nicolas" <nicolas dot blanc at intel dot com>]

>> session. In this context I think the text address is the most appropriate way to remove a file because:
>>   1) the user knows exactly where the .text section was loaded,
>
> So how do you handle the case of there being no .text section at all?

It's a requirement of the add-symbol-file command [1]. The existing implementation of add-symbol-file assumes
that the *mandatory* load-address argument (terminology from GDB's manual) is the address of the text section.
See the implementation of add-symbol-file:

	if (argcnt == 1)
	  {
	    /* The second argument is always the text address at which
               to load the program.  */
	    sect_opts[section_index].name = ".text";

The second argument is not optional. The add-symbol-file command returns an error if no address is specified.


>> Note that currently in Option 4 below ADDR is in fact 
>> "objf->addr_low", but the command could be more generous by searching 
>> first which file corresponds to ADDR and then removing it. This would be more flexible and an alternative to Option 3, for instance.
>You lost me here.

It's an idea that you and Tom gave me. Given an arbitrary address, remove-symbol-file could figure out the file that
corresponds to this address and remove it. This could make the command more flexible. But thinking twice I think that the current
implementation of remove-symbol-file does the right thing by identifying the file to remove using the address from the
add-symbol-file command. The user knows what address he passed to add-symbol-file.

>> 
>> 1) remove-symbol-file FILE
>> 2) remove-symbol-file FILE ADDR
>> 3) remove-symbol-file -s .data DATA_ADDR
>> 4) remove-symbol-file ADDR


[1] 
add-symbol-file filename address
add-symbol-file filename address [ -readnow ]
add-symbol-file filename address -s section address ...
The add-symbol-file command reads additional symbol table information from the file filename. You would use this command when filename has been dynamically loaded (by some other means) into the program that is running. address should be the memory address at which the file has been loaded; gdb cannot figure this out for itself.

Nicolas
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052