public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Guinevere Larsen <blarsen@redhat.com>
To: Carl Love <cel@us.ibm.com>, Simon Marchi <simark@simark.ca>,
	gdb-patches@sourceware.org,
	UlrichWeigand <Ulrich.Weigand@de.ibm.com>,
	pedro@palves.net
Cc: luis.machado@arm.com
Subject: Re: [PATCH 1/2 ver 2] Fix reverse stepping multiple contiguous PC ranges over the line table.
Date: Tue, 8 Aug 2023 12:04:09 +0200	[thread overview]
Message-ID: <387d9d9d-6f4f-696b-ff18-f68974a7da39@redhat.com> (raw)
In-Reply-To: <d0110a3c94c9fda8ea5a152a8a22004fc9ffdda9.camel@us.ibm.com>

On 07/08/2023 21:03, Carl Love wrote:
> Simon, GDB maintainers:
>
> Version 2, updated the compiler check and handling for gcc version 6
> and earlier.  Retested on Power 10.
>
> Per the comments on version 4 for the gdb.reverse/func-map-to-same-
> line.exp, I have added support to proc gdb_compile to enable or disable
> generating line information as part of the debug information.  The two
> new options are column-info and no-column-info.
>
> This patch implements the new options for gdb_compile.
>
> These options have been tested with patch 2 of 2 on PowerPC with the
> GCC and clang compilers.
>
> Please let me know if the patch is acceptable for mainline.   Thanks.
>
>                         Carl
>
>
> --------------------------
> Add gdb_compile options column-info and no-column-info
>
> This patch adds two new options to gdb_compile to specify if the compile
> should or should not generate the line table information.  The
> options are supported on clang and gcc version 7 and newer.
>
> Patch has been tested on PowerPC with both gcc and clang.
> ---
>   gdb/testsuite/lib/gdb.exp | 34 ++++++++++++++++++++++++++++++++++
>   1 file changed, 34 insertions(+)
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 36bf738c667..bffbbf38b09 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -4896,6 +4896,8 @@ proc quote_for_host { args } {
>   #     debug information
>   #   - text_segment=addr: Tell the linker to place the text segment at ADDR.
>   #   - build-id: Ensure the final binary includes a build-id.
> +#   - no-column-info: Disable generation of column table information.
> +#   - column-info: Enable generation of column table information.
>   #
>   # And here are some of the not too obscure options understood by DejaGnu that
>   # influence the compilation:
> @@ -5105,6 +5107,38 @@ proc gdb_compile {source dest type options} {
>               } else {
>                   error "Don't know how to handle text_segment option."
>               }
> +	} elseif { $opt == "column-info" } {
> +	    # If GCC or clang does not support column-info, compilation
> +	    # will fail and the usupported column-info option will be
> +	    # reported as such.
> +	    if {[test_compiler_info {gcc-*}]} {

I think you missed a bit on an old comment from simon. Way back in may, 
in this email 
https://sourceware.org/pipermail/gdb-patches/2023-May/199523.html, he 
mentioned:

For instance, if you used no-column-info with gcc 6
(which doesn't support column info at all), gdb_compile should succeed,
even if there isn't an option to disable column info with that compiler.
If you used column-info with gcc 6, gdb_compile would fail.

So I think this bit should throw an error if it detects gcc-[1-6].

> +		lappend new_options "additional_flags=-gcolumn-info"
> +
> +	    } elseif {[test_compiler_info {clang-*}]} {

I did some digging, and column-info were added in llvm back in october 
2012 (commit a2f7eb7c52cdc), which seems to mean support was added in 
llvm 3.2, but I don't see any mention in the release notes. In my 
opinion, this is old enough that we don't need to have a special case, 
but I wanted to mention, in case some maintainer thinks it should be 
dealt with.

If we should, before then, it seems that clang WOULD add column info by 
default, so it should compile with a warning here, and fail if the user 
requested no column info

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

> +		lappend new_options "additional_flags=-gcolumn-info"
> +
> +	    } else {
> +		error "Don't know how to handle gcolumn-info option."
> +	    }
> +
> +	} elseif { $opt == "no-column-info" } {
> +	    if {[test_compiler_info {gcc-*}]} {
> +		if {[test_compiler_info {gcc-[1-6]-*}]} {
> +		    # In this case, don't add the compile line option and
> +		    # the result will be the same as using no-column-info
> +		    # on a version that supports the option.
> +		    warning "gdb_compile option no-column-info not supported, ignoring."
> +		} else {
> +		    lappend new_options "additional_flags=-gno-column-info"
> +		}
> +
> +	    } elseif {[test_compiler_info {clang-*}]} {
> +		lappend new_options "additional_flags=-gno-column-info"
> +
> +	    } else {
> +		error "Don't know how to handle gno-column-info option."
> +	    }
> +
>           } else {
>               lappend new_options $opt
>           }


  reply	other threads:[~2023-08-08 10:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 18:54 [PATCH 0/2] " Carl Love
2023-08-07 19:03 ` [PATCH 1/2 ver 2] " Carl Love
2023-08-08 10:04   ` Guinevere Larsen [this message]
2023-08-08 15:38     ` Carl Love
2023-08-08 15:45       ` Guinevere Larsen
2023-08-07 19:03 ` [PATCH 2/2 ver 7] " Carl Love
2023-08-08 14:14   ` Guinevere Larsen
2023-08-08 15:52     ` Carl Love
  -- strict thread matches above, loose matches on Subject: below --
2023-04-27 20:59 [PATCH] " Carl Love
2023-05-03  9:53 ` Bruno Larsen
2023-05-04  2:55   ` [PATCH v2] " Carl Love
2023-05-04 15:59     ` [PATCH v3] " Carl Love
2023-05-10 13:47       ` Bruno Larsen
2023-05-10 17:16         ` Carl Love
2023-05-10 17:32           ` [PATCH v4] " Carl Love
2023-05-11 16:01             ` Simon Marchi
2023-05-11 16:23               ` Bruno Larsen
2023-05-11 17:28                 ` Simon Marchi
2023-05-16 22:54                   ` [PATCH 1/2] " Carl Love
2023-06-19 17:11                     ` Simon Marchi
2023-06-22 16:52                       ` Carl Love
2023-06-23 17:44                         ` Simon Marchi
2023-06-23 20:04                           ` [PATCH 1/2 ver 2] " Carl Love
2023-07-06 15:07                             ` Carl Love

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=387d9d9d-6f4f-696b-ff18-f68974a7da39@redhat.com \
    --to=blarsen@redhat.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=pedro@palves.net \
    --cc=simark@simark.ca \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).