From: Josef Ezra <jezra@emc.com>
Cc: gdb-patches@sources.redhat.com
Subject: [RFA] should gdb require '.text' and '.data' sections?
Date: Wed, 24 Apr 2002 06:45:00 -0000 [thread overview]
Message-ID: <3CC6B1E5.1080900@emc.com> (raw)
In-Reply-To: <3CBEFC88.37807AEF@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
Michael Snyder wrote:
>josef ezra wrote:
>
>>Hello
>>
>>I'm trying to debug a symbol file that has no '.text' section. Unlike 5.0
>>version, the new SECT_OFF_TEXT(objfile) macro calls (no-return) internal
>>error and prevent the read.
>>
>>Should gdb work that way (requiring '.text' and '.data' sections)?
>>
>>If not, can we consider the first sections flagged 'SEC_CODE'/'SEC_DATA' as
>>substitutes? Or maybe better have a default 0/1 values (like 5.0)? Both
>>should work in my case.
>>
>
>I agree, gdb should not require .text and .data. For one thing,
>a simple embedded assembler program might have no initialized data.
>For another, those segments might be called something else.
>
This patch will set objfile->sect_index_code/data index to the first
section that contains CODE/DATA flag when no section was named
'.text'/'.data'.
- jezra
bfd/ChangeLog:
* section.c (bfd_get_first_code_section): new function.
* section.c (bfd_get_first_data_section): new function.
* bfd-in2.h: Regenerated via 'make headers'.
gdb/ChangeLog:
* symfile.c ( default_symfile_offsets): default index for '.text' and
'.data' sections.
[-- Attachment #2: sect_index_bfd.pat --]
[-- Type: text/plain, Size: 1910 bytes --]
Index: bfd/section.c
===================================================================
RCS file: /cvs/src/src/bfd/section.c,v
retrieving revision 1.44
diff -u -3 -r1.44 section.c
--- bfd/section.c 30 Jan 2002 18:12:16 -0000 1.44
+++ bfd/section.c 19 Apr 2002 21:19:44 -0000
@@ -772,6 +772,56 @@
/*
FUNCTION
+ bfd_get_first_code_section
+
+SYNOPSIS
+ asection *bfd_get_first_code_section(bfd *abfd);
+
+DESCRIPTION
+ Run through @var{abfd} and return the first
+ <<asection>>s whose flagged SEC_CODE, <<NULL>>
+ @xref{Sections} if none (just in case .. )
+*/
+
+asection *
+bfd_get_first_code_section (abfd)
+ bfd *abfd;
+{
+ asection *sect;
+
+ for (sect = abfd->sections; sect != NULL; sect = sect->next)
+ if (sect->flags & SEC_CODE)
+ return sect;
+ return NULL;
+}
+
+/*
+FUNCTION
+ bfd_get_first_data_section
+
+SYNOPSIS
+ asection *bfd_get_first_data_section(bfd *abfd);
+
+DESCRIPTION
+ Run through @var{abfd} and return the first
+ <<asection>>s whose flagged SEC_DATA, <<NULL>>
+ @xref{Sections} if none (just in case .. )
+*/
+
+asection *
+bfd_get_first_data_section (abfd)
+ bfd *abfd;
+{
+ asection *sect;
+
+ for (sect = abfd->sections; sect != NULL; sect = sect->next)
+ if (sect->flags & SEC_DATA)
+ return sect;
+ return NULL;
+}
+
+/*
+FUNCTION
bfd_get_unique_section_name
SYNOPSIS
Index: bfd/bfd-in2.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in2.h,v
retrieving revision 1.149
diff -u -3 -r1.149 bfd-in2.h
--- bfd/bfd-in2.h 4 Apr 2002 19:53:34 -0000 1.149
+++ bfd/bfd-in2.h 19 Apr 2002 21:19:45 -0000
@@ -1401,6 +1401,12 @@
asection *
bfd_get_section_by_name PARAMS ((bfd *abfd, const char *name));
+
+asection *
+bfd_get_first_code_section PARAMS ((bfd *abfd));
+
+asection *
+bfd_get_first_data_section PARAMS ((bfd *abfd));
char *
bfd_get_unique_section_name PARAMS ((bfd *abfd,
[-- Attachment #3: sect_index_gdb.pat --]
[-- Type: text/plain, Size: 712 bytes --]
Index: gdb/symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.58
diff -u -3 -r1.58 symfile.c
--- gdb/symfile.c 29 Mar 2002 01:09:27 -0000 1.58
+++ gdb/symfile.c 22 Apr 2002 13:05:51 -0000
@@ -522,10 +522,14 @@
.rodata sections. */
sect = bfd_get_section_by_name (objfile->obfd, ".text");
+ if (!sect)
+ sect = bfd_get_first_code_section (objfile->obfd);
if (sect)
objfile->sect_index_text = sect->index;
sect = bfd_get_section_by_name (objfile->obfd, ".data");
+ if (!sect)
+ sect = bfd_get_first_data_section (objfile->obfd) ;
if (sect)
objfile->sect_index_data = sect->index;
next prev parent reply other threads:[~2002-04-24 13:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 8:11 josef ezra
2002-04-18 11:15 ` Michael Snyder
2002-04-22 6:32 ` Josef Ezra
2002-04-24 6:45 ` Josef Ezra [this message]
2002-06-13 10:06 ` Request for new gdb command: 'info orientation' Josef Ezra
2002-06-13 10:35 ` Andrew Cagney
2002-06-13 11:06 ` Michael Snyder
2002-06-13 11:20 ` Josef Ezra
2002-06-17 12:34 ` [RFA] new command: 'maintenance info lines' Josef Ezra
2002-06-17 22:26 ` Eli Zaretskii
2002-06-18 13:47 ` josef ezra
2002-06-18 14:42 ` Michael Snyder
2002-06-18 22:42 ` Eli Zaretskii
2002-06-19 7:27 ` Josef Ezra
2002-06-18 14:35 ` Michael Snyder
2002-09-06 5:08 ` Josef Ezra
2002-09-18 22:33 ` Eli Zaretskii
2002-09-23 8:06 ` Josef Ezra
2002-09-23 22:12 ` Eli Zaretskii
2002-09-25 13:26 ` Fernando Nasser
2002-09-26 6:49 ` Josef Ezra
2002-09-26 10:45 ` Fernando Nasser
2002-09-26 19:03 ` Andrew Cagney
2002-09-06 13:44 ` Josef Ezra
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=3CC6B1E5.1080900@emc.com \
--to=jezra@emc.com \
--cc=gdb-patches@sources.redhat.com \
/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