add-symbol-file/load and scripts

add-symbol-file/load and scripts

[Jerome Guitton]

Hello,

I would like to have your opinion on a small improvement that I am
considering in add-symbol-file/load.

add-symbol-file takes two mandatory parameters: the name of symbol
file and the address of the text section. It can be asked if the
second parameter can be optional; the text's address, as initialized
in the symbol file itself, would be the appropriate defaut.

The rational of this suggestion is to use the same default as the load
command, when it is implemented as in generic_load (GDB writing
directly into the target's memory). In this case, the load address is
the address of the text section (if no offset is given in parameter).
For now, in this default case, the user has to copy-paste the address
from the output of the load command to feed it to add-symb... This user
can feel that GDB could have guessed where the file had been loaded, as
it just gave it in the output:

(gdb) load module_1.elf
   Loading section .text, size 0x50 lma 0x6c0000
   Loading section .spare, size 0xb0 lma 0x6c0050
   Loading section .text, size 0x6c lma 0x6c0100
   Loading section .spare, size 0x294 lma 0x6c016c
   Loading section .text, size 0x3c4c lma 0x6c0400
   Loading section .spare, size 0x43b4 lma 0x6c404c
   Loading section .text, size 0x73a8 lma 0x6c8400
   Loading section .spare, size 0x20858 lma 0x6cf7a8
   Start address 0x6c0000, load size 196608
(gdb) add-symbol-file module_1.elf 0x6c0000

And the copy-paste thing makes it difficult to use add-symbol-file
into a script, of course.

We can ask ourselves if 0x6c000 would not have been an appropriate default
for the second parameter of add-symbol-file... I am not sure it makes
complete sense for any object format, though.

Another solution may just be to set "$_" to the start address of the
module after the load. In which case, the user would just have to do:

(gdb) load module_1.elf
[...]
(gdb) add-symbol-file module_1.elf $_

The thing is, GDB may not be able to know the start address of the
module that it just loaded. I depends on the target implementation of
load. But I do not think that it is the case in general. We may handle
these cases by setting $_ to void.

Any of the solutions are easy to implement. And they both make it
possible to use these commands in a script.

Opinions/thoughts?

Re: add-symbol-file/load and scripts

[Paul Pluzhnikov]

On Tue, Jun 2, 2009 at 9:27 AM, Jerome Guitton <guitton@adacore.com> wrote:

> the text's address, as initialized
> in the symbol file itself, would be the appropriate defaut.

AFAIU, on any UNIX system it would be appropriate default *only* for ET_EXEC.
For non-prelinked ET_DYN, one needs to add the base load address.

> We can ask ourselves if 0x6c000 would not have been an appropriate default
> for the second parameter of add-symbol-file... I am not sure it makes
> complete sense for any object format, though.

I think you've restricted your universe in the above statement to embedded
systems. My universe does not intersect with it :-(

Cheers,
-- 
Paul Pluzhnikov

Re: add-symbol-file/load and scripts

[Jerome Guitton]

Paul Pluzhnikov (ppluzhnikov@google.com):

> On Tue, Jun 2, 2009 at 9:27 AM, Jerome Guitton <guitton@adacore.com> wrote:
> 
> > the text's address, as initialized
> > in the symbol file itself, would be the appropriate defaut.
> 
> AFAIU, on any UNIX system it would be appropriate default *only* for ET_EXEC.
> For non-prelinked ET_DYN, one needs to add the base load address.

Thank you for pointing this out! This definitely rules out the first
solution.

So, what about the second possibility? (That is to say: when it is
possible, setting a convenience variable to the start address after
load).

Re: add-symbol-file/load and scripts

[Doug Evans]

On Tue, Jun 2, 2009 at 10:04 AM, Jerome Guitton <guitton@adacore.com> wrote:
> Paul Pluzhnikov (ppluzhnikov@google.com):
>
>> On Tue, Jun 2, 2009 at 9:27 AM, Jerome Guitton <guitton@adacore.com> wrote:
>>
>> > the text's address, as initialized
>> > in the symbol file itself, would be the appropriate defaut.
>>
>> AFAIU, on any UNIX system it would be appropriate default *only* for ET_EXEC.
>> For non-prelinked ET_DYN, one needs to add the base load address.
>
> Thank you for pointing this out! This definitely rules out the first
> solution.
>
> So, what about the second possibility? (That is to say: when it is
> possible, setting a convenience variable to the start address after
> load).

With a better scripting language with better tools for access to elf
files (a small subset of all of the various kinds of things one would
like to be able to script better), one could pass the .elf file to a
function and it would return the desired value.

add-symbol-file foo.elf $elf.load_address ("foo.elf")    # [just
winging syntax here, it's subordinate to the main point]

Re: add-symbol-file/load and scripts

[Paul Pluzhnikov]

On Tue, Jun 2, 2009 at 10:26 AM, Doug Evans <dje@google.com> wrote:

> add-symbol-file foo.elf $elf.load_address ("foo.elf")    # [just
> winging syntax here, it's subordinate to the main point]

I think you can already do this with python support:

  my_load foo.elf

Where my_load is a python command, which parses foo.elf, loads it, and
adds symbols for it. IOW, there is no real need to extend add-symbol-file
anymore.
-- 
Paul Pluzhnikov

Re: add-symbol-file/load and scripts

[Daniel Jacobowitz]

On Tue, Jun 02, 2009 at 11:41:03AM -0700, Paul Pluzhnikov wrote:
> I think you can already do this with python support:
> 
>   my_load foo.elf
> 
> Where my_load is a python command, which parses foo.elf, loads it, and
> adds symbols for it. IOW, there is no real need to extend add-symbol-file
> anymore.

IMO, this doesn't rule out a sensible default.  Your comment about the
embedded universe was accurate - but in the Linux desktop universe,
you should almost never need this command anyway.

-- 
Daniel Jacobowitz
CodeSourcery