RE: [PING] [PATCH v2] Bug 17394: we cannot put a break-point at a global function for ASM file

mihail.nistor
2014-12-10T21:11:28Z

Hello global maintainers,

The deadline to receive the review for patch from a maintainer expired. Keith Seitz required a review from a maintainer for this patch on 30 September 2014.

Please help us to find a maintainer that can do the review for this patch.

Thank you in advance for your support.

Mihai

-----Original Message-----
From: Nistor Mihail-MNISTOR1
Sent: Tuesday, December 09, 2014 5:02 PM
To: 'gdb-patches@sourceware.org'; 'palves@redhat.com'
Cc: 'keiths@redhat.com'
Subject: FW: [PING] [PATCH v2] Bug 17394: we cannot put a break-point at a global function for ASM file

Hello Pedro,

We need support from a maintainer to give the final approval for this patch. Can you please help us to look over this patch or recommend another maintainer to do it.

Thank you,
Mihai
-----Original Message-----
From: Nistor Mihail-MNISTOR1
Sent: Saturday, November 15, 2014 7:35 PM
To: 'gdb-patches@sourceware.org'
Cc: 'Keith Seitz'
Subject: FW:[PING] [PATCH v2] Bug 17394: we cannot put a break-point at a global function for ASM file

Dear all,

I would like to remind you that the patch attached is still pending for the final approval.
When we last exchanged messages there seemed to be no problem; has anything happened since ?
I'm looking forward to your reply.

Thank you,
Mihai

-----Original Message-----
From: Keith Seitz [mailto:keiths@redhat.com]
Sent: Tuesday, September 30, 2014 10:45 PM
To: Nistor Mihail-MNISTOR1; gdb-patches@sourceware.org
Subject: Re: [PATCH v2] Bug 17394: we cannot put a break-point at a global function for ASM file

On 09/28/2014 09:08 AM, mihail.nistor@freescale.com wrote:
> -----Original Message-----
> From: Nistor Mihail-MNISTOR1
> Sent: Sunday, September 28, 2014 6:47 PM
> To: Keith Seitz; gdb-patches@sourceware.org
> Cc: Nistor Mihail-MNISTOR1
> Subject: RE: [PATCH v2] Bug 17394: we cannot put a break-point at a
> global function for ASM file
>
> Your changes look very well, I have one little observation regarding the filtering condition when we need to get information from minimal symbol.
> Scenario: We can mix objects that were compiled/assembled by different vendors and the third party assembler provides debug information and it doesn't have this limitation. An application may contain more than one file that have the same name. We cannot put a breakpoint at a function in all objects that have the same name if an object that comes from ASM file has debug info and is linked before the objects assembled with the GNU-GAS. In the new test case I have tried to emulate the third party assembler behavior in the break-asm-file1.s.
>

That makes sense to me. FWIW, here is a combined patch which I think a maintainer should give a final look over.

Thank you for the patch!
Keith

gdb/ChangeLog:
2014-09-30 Keith Seitz <keiths@redhat.com>
Mihail-Marian Nistor <mihail.nistor@freescale.com>

PR gdb/17394
* linespec.c (struct collect_minsyms): Add new member `symtab'.
(add_minsym): Handle cases where info.symtab is non-NULL.
(search_minsyms_for_name): Add new parameter `symtab'.
Handle limiting searches to a specific symtab.
(add_matching_symtabs_to_info): Search through minimal symbols
for language_asm files for which no new symbols are found.

gdb/testsuite/ChangeLog:
2014-09-30 Mihail-Marian Nistor <mihail.nistor@freescale.com>

PR gdb/17394
* gdb.linespec/break-asm-file.c: New file.
* gdb.linespec/break-asm-file.exp: New file.
* gdb.linespec/break-asm-file0.s: New file.
* gdb.linespec/break-asm-file1.s: New file.