Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jerome Guitton <guitton@adacore.com>
To: gdb@sourceware.org
Subject: add-symbol-file/load and scripts
Date: Tue, 02 Jun 2009 16:27:00 -0000	[thread overview]
Message-ID: <20090602162718.GA21116@adacore.com> (raw)

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?



             reply	other threads:[~2009-06-02 16:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 16:27 Jerome Guitton [this message]
2009-06-02 16:48 ` Paul Pluzhnikov
2009-06-02 17:04   ` Jerome Guitton
2009-06-02 17:26     ` Doug Evans
2009-06-02 18:41       ` Paul Pluzhnikov
2009-06-02 19:40         ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090602162718.GA21116@adacore.com \
    --to=guitton@adacore.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox