[PATCHv4] gdb: fix handling of DW_AT_entry_pc of inlined subroutines
Checks
Context |
Check |
Description |
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Build passed
|
linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Build passed
|
linaro-tcwg-bot/tcwg_gdb_check--master-arm |
success
|
Test passed
|
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
success
|
Test passed
|
Commit Message
In v4:
- I still have one failed being reported from Linaro CI,
gdb.stabs/gdb11479.exp. I've been unable to reproduce this
failure. However, on re-reading this patch I did notice that, if
the m_entry_pc field was not set then we would still end up giving
it a value during relocation, this would result in m_entry_pc
holding an address which had been relocated twice.
Fixed this by moving the block's address relocation logic into the
block class, and only relocating the m_entry_pc variable if it
actually has been assigned a value.
In v3:
- Entry PC values are now clamped to the block's start/end range.
This was causing failures in the self-tests when GDB was compiled
with GCC using default optimisation, as GCC emits an (invalid?)
entry-pc which is outside the blocks start/end range.
In v2:
- Don't use std::optional<CORE_ADDR> for block::m_entry_pc, instead
just use CORE_ADDR. This does mean that targets where 0 is a
valid code address might run into problems, but those targets
likely have plenty of other problems, and I'd rather land this fix
than get hung up on this edge case.
In the future it might be possible to remove block::m_start and
block::m_end as Klaus suggested, but this doesn't look like a
simple task. If we did drop those fields then it might be
possible to space a word for some flag bits which would allow us
to remove the 0 address special case.
- Fixes to the DWARF assembler testcase to handle compiling with
'-pie', the Linaro CI exposed these issues. The changes are
pretty minor, mostly using label names rather than addresses when
building the DWARF.
---
The entry PC for a DIE, e.g. an inline function, might not be the base
address of the DIE. Currently though, in block::entry_pc(), GDB
always returns the base address (low-pc or the first address of the
first range) as the entry PC.
This commit extends the block class to carry the entry PC as a
separate member variable. Then the DWARF reader is extended to read
and set the entry PC for the block. Now in block::entry_pc(), if the
entry PC has been set to a specific value, this is the value returned.
I have not removed the old code in block::entry_pc(). If the specific
entry PC value was not set then we still fall back on the old approach
of just returning the base address. Doing this feels more useful than
just claiming there is no entry PC. This should also mean that we
shouldn't see any change in behaviour for compilers that don't emit
the DW_AT_entry_pc, or for debug readers (e.g. stabs) that don't set
the entry PC value within a block.
The DWARF-5 spec for reading the entry PC is a super-set of the spec
as found in DWARF-4. For example, if there is no DW_AT_entry_pc then
DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base
address, which is DW_AT_low_pc or the first address in the first range
specified by DW_AT_ranges if there is no DW_AT_low_pc.
I have taken the approach of just implementing the DWARF-5 spec for
everyone. There doesn't seem to be any benefit to deliberately
ignoring a ranges based entry PC value for DWARF-4. If some naughty
compiler has emitted that, then lets use it.
Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5
allows an address or a constant, where the constant is an offset from
the base address. I allow both approaches for all DWARF versions.
There doesn't seem to be any downsides to this approach.
There was one issue that I ran into when testing this patch. GCC
seems to be quite bad at tracking code ranges when the default level
of optimisation is applied. As a result I was seeing failures in
gdb.gdb/python-helper.exp and gdb.gdb/selftest.exp when we debug the
generated GDB executable.
What happens is that the DW_AT_entry_pc is given as an entry address
which is outside of any of the blocks ranges. Previously we ignored
the DW_AT_entry_pc and when we later ask for the entry-pc we just
report the first range's start address.
After this commit we track the declared entry-pc, which is then what
we report.
What this means is that when the user (or DejaGNU) tries to place a
breakpoint on an inline function, the breakpoint is placed at the
entry-pc. Then when GDB stops at this address and tries to figure out
which block it's in, GDB doesn't think it's actually within the inline
function that the user asked to stop in.
In the test I mention about we place a breakpoint within GDB's
'captured_main' function. In the builds I was looked at, this
function was inline within 'gdb_main', but the DW_AT_entry_pc for the
'captured_main' function was not within the declared ranges of
'captured_main'. As a result when the breakpoint was hit, GDB would
report the inferior as within 'gdb_main' instead of 'captured_main'.
For now I propose fixing this by checking the entry-pc against the
blocks start address. If the entry-pc is before the start address
then we move the entry-pc to be the start address. This effectively
restores the pre-patch behaviour for this problem case.
In the future I think we might be able to do better than this, I'd
like to have GDB examine the line table and then possibly extend the
block's ranges to start at the entry-pc, rather than moving the
entry-pc, but this will require additional infrastructure changes in
GDB. As the fix I propose here is basically "maintain the status quo"
I'm hoping this will be acceptable, and a better solution can be added
later.
As part of this commit I've moved the code that relocates a block's
addresses from objfiles.c (function objfile_relocate1) into the block
class as block::relocate_addresses(). This allows the entry-pc to be
relocated correctly when this variable's value is optional.
The inline-entry.exp test was originally contributed by Bernd here:
https://inbox.sourceware.org/gdb-patches/AS1PR01MB94659E4D9B3F4A6006CC605FE4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com
though I have made some edits, making more use of lib/gdb.exp
functions, making the gdb_test output patterns a little tighter, and
updating the test to run with Clang. I also moved the test to
gdb.opt/ as that seemed like a better home for it.
Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
---
gdb/block.c | 19 +
gdb/block.h | 49 ++-
gdb/dwarf2/read.c | 105 ++++-
gdb/objfiles.c | 9 +-
gdb/testsuite/gdb.dwarf2/dw2-entry-pc.c | 51 +++
gdb/testsuite/gdb.dwarf2/dw2-entry-pc.exp | 487 ++++++++++++++++++++++
gdb/testsuite/gdb.opt/inline-entry.c | 41 ++
gdb/testsuite/gdb.opt/inline-entry.exp | 51 +++
8 files changed, 791 insertions(+), 21 deletions(-)
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-entry-pc.c
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-entry-pc.exp
create mode 100644 gdb/testsuite/gdb.opt/inline-entry.c
create mode 100644 gdb/testsuite/gdb.opt/inline-entry.exp
base-commit: a723c56efb07c4f8b3f6a3ed4b878a2f8f5572cc
Comments
Hi Andrew,
On 10/29/24 15:49, Andrew Burgess wrote:
> In v4:
>
> - I still have one failed being reported from Linaro CI,
> gdb.stabs/gdb11479.exp. I've been unable to reproduce this
> failure. However, on re-reading this patch I did notice that, if
> the m_entry_pc field was not set then we would still end up giving
> it a value during relocation, this would result in m_entry_pc
> holding an address which had been relocated twice.
>
> Fixed this by moving the block's address relocation logic into the
> block class, and only relocating the m_entry_pc variable if it
> actually has been assigned a value.
>
> In v3:
>
> - Entry PC values are now clamped to the block's start/end range.
> This was causing failures in the self-tests when GDB was compiled
> with GCC using default optimisation, as GCC emits an (invalid?)
> entry-pc which is outside the blocks start/end range.
>
> In v2:
>
> - Don't use std::optional<CORE_ADDR> for block::m_entry_pc, instead
> just use CORE_ADDR. This does mean that targets where 0 is a
> valid code address might run into problems, but those targets
> likely have plenty of other problems, and I'd rather land this fix
> than get hung up on this edge case.
>
> In the future it might be possible to remove block::m_start and
> block::m_end as Klaus suggested, but this doesn't look like a
> simple task. If we did drop those fields then it might be
> possible to space a word for some flag bits which would allow us
> to remove the 0 address special case.
>
> - Fixes to the DWARF assembler testcase to handle compiling with
> '-pie', the Linaro CI exposed these issues. The changes are
> pretty minor, mostly using label names rather than addresses when
> building the DWARF.
>
> ---
>
> The entry PC for a DIE, e.g. an inline function, might not be the base
> address of the DIE. Currently though, in block::entry_pc(), GDB
> always returns the base address (low-pc or the first address of the
> first range) as the entry PC.
>
> This commit extends the block class to carry the entry PC as a
> separate member variable. Then the DWARF reader is extended to read
> and set the entry PC for the block. Now in block::entry_pc(), if the
> entry PC has been set to a specific value, this is the value returned.
>
> I have not removed the old code in block::entry_pc(). If the specific
> entry PC value was not set then we still fall back on the old approach
> of just returning the base address. Doing this feels more useful than
> just claiming there is no entry PC. This should also mean that we
> shouldn't see any change in behaviour for compilers that don't emit
> the DW_AT_entry_pc, or for debug readers (e.g. stabs) that don't set
> the entry PC value within a block.
>
> The DWARF-5 spec for reading the entry PC is a super-set of the spec
> as found in DWARF-4. For example, if there is no DW_AT_entry_pc then
> DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base
> address, which is DW_AT_low_pc or the first address in the first range
> specified by DW_AT_ranges if there is no DW_AT_low_pc.
>
> I have taken the approach of just implementing the DWARF-5 spec for
> everyone. There doesn't seem to be any benefit to deliberately
> ignoring a ranges based entry PC value for DWARF-4. If some naughty
> compiler has emitted that, then lets use it.
>
> Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5
> allows an address or a constant, where the constant is an offset from
> the base address. I allow both approaches for all DWARF versions.
> There doesn't seem to be any downsides to this approach.
>
> There was one issue that I ran into when testing this patch. GCC
> seems to be quite bad at tracking code ranges when the default level
> of optimisation is applied. As a result I was seeing failures in
> gdb.gdb/python-helper.exp and gdb.gdb/selftest.exp when we debug the
> generated GDB executable.
>
> What happens is that the DW_AT_entry_pc is given as an entry address
> which is outside of any of the blocks ranges. Previously we ignored
> the DW_AT_entry_pc and when we later ask for the entry-pc we just
> report the first range's start address.
>
> After this commit we track the declared entry-pc, which is then what
> we report.
>
> What this means is that when the user (or DejaGNU) tries to place a
> breakpoint on an inline function, the breakpoint is placed at the
> entry-pc. Then when GDB stops at this address and tries to figure out
> which block it's in, GDB doesn't think it's actually within the inline
> function that the user asked to stop in.
>
> In the test I mention about we place a breakpoint within GDB's
> 'captured_main' function. In the builds I was looked at, this
> function was inline within 'gdb_main', but the DW_AT_entry_pc for the
> 'captured_main' function was not within the declared ranges of
> 'captured_main'. As a result when the breakpoint was hit, GDB would
> report the inferior as within 'gdb_main' instead of 'captured_main'.
>
I think you might have hit a case that I mentioned on part 3 of my patch:
Additionally it may happen that one inline sub-range
is empty or the inline is completely empty. But
filtering that information away is not the right
solution, since although there is no actual code
from the inline, it is still possible that variables
from an inline function can be inspected here.
You probably had the entry_pc pointing to an empty sub-range,
that is usually the lowest address, currently that is filtered
away by the dwarf reader, but part 2+3 change that behavior,
but since I did not try to solve the entry_pc problem completely,
there was no apparent dependency between part 1 and part 2+3.
But probably this is no longer the case, with your patch,
since the checks are more strict, you could try to layer
your entry_pc path over part 2+3.
> For now I propose fixing this by checking the entry-pc against the
> blocks start address. If the entry-pc is before the start address
> then we move the entry-pc to be the start address. This effectively
> restores the pre-patch behaviour for this problem case.
>
I think this plausibilty check is not strict enough, instead of just
checking against the low and hig bounds, you should only accept the
entry_pc value if it is inside the bounds of any of the sub-ranges,
since we have no chance to get the correct behaviour otherwise, and
the previous state is to prefer in that case.
Thanks
Bernd.
On 10/29/24 15:49, Andrew Burgess wrote:
> @@ -344,6 +357,18 @@ struct block : public allocate_on_obstack<block>
> startaddr and endaddr above. */
>
> struct blockranges *m_ranges = nullptr;
> +
> + /* The entry address for this block. The value 0 is special and
> + indicates that the entry address has not been set.
> +
> + Using 0 as a special value is not ideal, targets for which 0 is a
> + valid code address might run into problems if they want to use 0 as a
> + block's entry address, but the alternative is to carry a flag
> + indicating if m_entry_pc is valid or not, but that would make 'struct
> + block' even bigger, and we want to keep 'struct block' as small as
> + possible (we might have a lot of blocks). */
> +
> + CORE_ADDR m_entry_pc = 0;
> };
>
Aehm, I've just had an idea how you can get this much simpler:
Instead of using an exceptional value, and fiddle with the later relocation steps,
you should simply store here the offset from ranges[0].start, or block.start
if no subranges, this is just a constant value, that just has to be added in
block.entry_pc(), 0 means just the current behavour, and if >0 it is always a
constant value, even after objfile relocation. That means there is no chance of any
special value that cannot be handled here, and a lot of complications can be avoided.
What do you think?
Thanks
Bernd.
Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> Hi Andrew,
>
> On 10/29/24 15:49, Andrew Burgess wrote:
>> In v4:
>>
>> - I still have one failed being reported from Linaro CI,
>> gdb.stabs/gdb11479.exp. I've been unable to reproduce this
>> failure. However, on re-reading this patch I did notice that, if
>> the m_entry_pc field was not set then we would still end up giving
>> it a value during relocation, this would result in m_entry_pc
>> holding an address which had been relocated twice.
>>
>> Fixed this by moving the block's address relocation logic into the
>> block class, and only relocating the m_entry_pc variable if it
>> actually has been assigned a value.
>>
>> In v3:
>>
>> - Entry PC values are now clamped to the block's start/end range.
>> This was causing failures in the self-tests when GDB was compiled
>> with GCC using default optimisation, as GCC emits an (invalid?)
>> entry-pc which is outside the blocks start/end range.
>>
>> In v2:
>>
>> - Don't use std::optional<CORE_ADDR> for block::m_entry_pc, instead
>> just use CORE_ADDR. This does mean that targets where 0 is a
>> valid code address might run into problems, but those targets
>> likely have plenty of other problems, and I'd rather land this fix
>> than get hung up on this edge case.
>>
>> In the future it might be possible to remove block::m_start and
>> block::m_end as Klaus suggested, but this doesn't look like a
>> simple task. If we did drop those fields then it might be
>> possible to space a word for some flag bits which would allow us
>> to remove the 0 address special case.
>>
>> - Fixes to the DWARF assembler testcase to handle compiling with
>> '-pie', the Linaro CI exposed these issues. The changes are
>> pretty minor, mostly using label names rather than addresses when
>> building the DWARF.
>>
>> ---
>>
>> The entry PC for a DIE, e.g. an inline function, might not be the base
>> address of the DIE. Currently though, in block::entry_pc(), GDB
>> always returns the base address (low-pc or the first address of the
>> first range) as the entry PC.
>>
>> This commit extends the block class to carry the entry PC as a
>> separate member variable. Then the DWARF reader is extended to read
>> and set the entry PC for the block. Now in block::entry_pc(), if the
>> entry PC has been set to a specific value, this is the value returned.
>>
>> I have not removed the old code in block::entry_pc(). If the specific
>> entry PC value was not set then we still fall back on the old approach
>> of just returning the base address. Doing this feels more useful than
>> just claiming there is no entry PC. This should also mean that we
>> shouldn't see any change in behaviour for compilers that don't emit
>> the DW_AT_entry_pc, or for debug readers (e.g. stabs) that don't set
>> the entry PC value within a block.
>>
>> The DWARF-5 spec for reading the entry PC is a super-set of the spec
>> as found in DWARF-4. For example, if there is no DW_AT_entry_pc then
>> DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base
>> address, which is DW_AT_low_pc or the first address in the first range
>> specified by DW_AT_ranges if there is no DW_AT_low_pc.
>>
>> I have taken the approach of just implementing the DWARF-5 spec for
>> everyone. There doesn't seem to be any benefit to deliberately
>> ignoring a ranges based entry PC value for DWARF-4. If some naughty
>> compiler has emitted that, then lets use it.
>>
>> Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5
>> allows an address or a constant, where the constant is an offset from
>> the base address. I allow both approaches for all DWARF versions.
>> There doesn't seem to be any downsides to this approach.
>>
>> There was one issue that I ran into when testing this patch. GCC
>> seems to be quite bad at tracking code ranges when the default level
>> of optimisation is applied. As a result I was seeing failures in
>> gdb.gdb/python-helper.exp and gdb.gdb/selftest.exp when we debug the
>> generated GDB executable.
>>
>> What happens is that the DW_AT_entry_pc is given as an entry address
>> which is outside of any of the blocks ranges. Previously we ignored
>> the DW_AT_entry_pc and when we later ask for the entry-pc we just
>> report the first range's start address.
>>
>> After this commit we track the declared entry-pc, which is then what
>> we report.
>>
>> What this means is that when the user (or DejaGNU) tries to place a
>> breakpoint on an inline function, the breakpoint is placed at the
>> entry-pc. Then when GDB stops at this address and tries to figure out
>> which block it's in, GDB doesn't think it's actually within the inline
>> function that the user asked to stop in.
>>
>> In the test I mention about we place a breakpoint within GDB's
>> 'captured_main' function. In the builds I was looked at, this
>> function was inline within 'gdb_main', but the DW_AT_entry_pc for the
>> 'captured_main' function was not within the declared ranges of
>> 'captured_main'. As a result when the breakpoint was hit, GDB would
>> report the inferior as within 'gdb_main' instead of 'captured_main'.
>>
>
> I think you might have hit a case that I mentioned on part 3 of my patch:
>
> Additionally it may happen that one inline sub-range
> is empty or the inline is completely empty. But
> filtering that information away is not the right
> solution, since although there is no actual code
> from the inline, it is still possible that variables
> from an inline function can be inspected here.
>
> You probably had the entry_pc pointing to an empty sub-range,
> that is usually the lowest address, currently that is filtered
> away by the dwarf reader, but part 2+3 change that behavior,
> but since I did not try to solve the entry_pc problem completely,
> there was no apparent dependency between part 1 and part 2+3.
> But probably this is no longer the case, with your patch,
> since the checks are more strict, you could try to layer
> your entry_pc path over part 2+3.
You are correct that the entry-pc is pointing to an empty sub-range.
And as you say, if we later (as I think we should) merge those parts of
your series that deal with empty sub-ranges, then this will resolve this
problem and allow the entry-pc to point to a non-empty range.
I would however, like to avoid, if at all possible, making this change
depend on the later work, and if we follow up on your following
suggestion, then I think the dependency is gone.
>
>> For now I propose fixing this by checking the entry-pc against the
>> blocks start address. If the entry-pc is before the start address
>> then we move the entry-pc to be the start address. This effectively
>> restores the pre-patch behaviour for this problem case.
>>
>
> I think this plausibilty check is not strict enough, instead of just
> checking against the low and hig bounds, you should only accept the
> entry_pc value if it is inside the bounds of any of the sub-ranges,
That's a reasonable position to take, and it's trivial to change the
patch to do this. It's worth pointing out that ignoring the entry-pc is
(currently) the same as just using the lower bound. But I'll make this
change and post a v4.
> since we have no chance to get the correct behaviour otherwise, and
> the previous state is to prefer in that case.
I don't understand what you mean by "the previous state is to prefer in
that case", so I'm not sure if I've missed something important here.
Could you clarify this point please.
Thanks,
Andrew
Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> On 10/29/24 15:49, Andrew Burgess wrote:
>> @@ -344,6 +357,18 @@ struct block : public allocate_on_obstack<block>
>> startaddr and endaddr above. */
>>
>> struct blockranges *m_ranges = nullptr;
>> +
>> + /* The entry address for this block. The value 0 is special and
>> + indicates that the entry address has not been set.
>> +
>> + Using 0 as a special value is not ideal, targets for which 0 is a
>> + valid code address might run into problems if they want to use 0 as a
>> + block's entry address, but the alternative is to carry a flag
>> + indicating if m_entry_pc is valid or not, but that would make 'struct
>> + block' even bigger, and we want to keep 'struct block' as small as
>> + possible (we might have a lot of blocks). */
>> +
>> + CORE_ADDR m_entry_pc = 0;
>> };
>>
>
> Aehm, I've just had an idea how you can get this much simpler:
>
> Instead of using an exceptional value, and fiddle with the later relocation steps,
> you should simply store here the offset from ranges[0].start, or block.start
> if no subranges, this is just a constant value, that just has to be added in
> block.entry_pc(), 0 means just the current behavour, and if >0 it is always a
> constant value, even after objfile relocation. That means there is no chance of any
> special value that cannot be handled here, and a lot of complications can be avoided.
>
> What do you think?
I like it. I'll give this a go and see what this looks like in v4.
Thanks for the great suggestion.
Andrew
On 10/31/24 11:57, Andrew Burgess wrote:
> Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
>> since we have no chance to get the correct behaviour otherwise, and
>> the previous state is to prefer in that case.
>
> I don't understand what you mean by "the previous state is to prefer in
> that case", so I'm not sure if I've missed something important here.
> Could you clarify this point please.
>
Okay, I wanted to say, if the entry_pc is outside of any sub-range, we should
complain about it, but ignore the value, so the user should no see any
difference to the debugging of that code with the gdb before this patch.
Thanks
Bernd.
Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> On 10/31/24 11:57, Andrew Burgess wrote:
>> Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
>>> since we have no chance to get the correct behaviour otherwise, and
>>> the previous state is to prefer in that case.
>>
>> I don't understand what you mean by "the previous state is to prefer in
>> that case", so I'm not sure if I've missed something important here.
>> Could you clarify this point please.
>>
>
> Okay, I wanted to say, if the entry_pc is outside of any sub-range, we should
> complain about it, but ignore the value, so the user should no see any
> difference to the debugging of that code with the gdb before this patch.
Great. I think we're now aligned on this then. I'm about to post v5
which does this, let me know what you think.
Thanks,
Andrew
@@ -118,6 +118,25 @@ block::inlined_p () const
return function () != nullptr && function ()->is_inlined ();
}
+/* See block.h. */
+
+void
+block::relocate_addresses (CORE_ADDR delta)
+{
+ m_start += delta;
+ m_end += delta;
+
+ if (m_entry_pc != 0)
+ m_entry_pc += delta;
+
+ for (blockrange &r : this->ranges ())
+ {
+ r.set_start (r.start () + delta);
+ r.set_end (r.end () + delta);
+ }
+}
+
+
/* A helper function that checks whether PC is in the blockvector BL.
It returns the containing block if there is one, or else NULL. */
@@ -179,27 +179,35 @@ struct block : public allocate_on_obstack<block>
/* Return the "entry PC" of this block.
- The entry PC is the lowest (start) address for the block when all addresses
- within the block are contiguous. If non-contiguous, then use the start
- address for the first range in the block.
-
- At the moment, this almost matches what DWARF specifies as the entry
- pc. (The missing bit is support for DW_AT_entry_pc which should be
- preferred over range data and the low_pc.)
+ If the entry PC has been set to a specific value then this is
+ returned. Otherwise, the entry PC is the lowest (start) address for
+ the block when all addresses within the block are contiguous. If
+ non-contiguous, then use the start address for the first range in the
+ block.
- Once support for DW_AT_entry_pc is added, I expect that an entry_pc
- field will be added to one of these data structures. Once that's done,
- the entry_pc field can be set from the dwarf reader (and other readers
- too). ENTRY_PC can then be redefined to be less DWARF-centric. */
+ This almost matches what DWARF specifies as the entry pc, except that
+ the final case, using the first address of the first range, is a GDB
+ extension. However, the DWARF reader sets the specific entry PC
+ wherever possible, so this non-standard fallback case is only used as
+ a last resort. */
CORE_ADDR entry_pc () const
{
- if (this->is_contiguous ())
+ if (m_entry_pc != 0)
+ return m_entry_pc;
+ else if (this->is_contiguous ())
return this->start ();
else
return this->ranges ()[0].start ();
}
+ /* Set this block's entry PC. */
+
+ void set_entry_pc (CORE_ADDR addr)
+ {
+ m_entry_pc = addr;
+ }
+
/* Return the objfile of this block. */
struct objfile *objfile () const;
@@ -306,6 +314,11 @@ struct block : public allocate_on_obstack<block>
bool contains (const struct block *a, bool allow_nested = false) const;
+ /* Adjust m_start, m_end, and m_entry_pc by DELTA. Also update the
+ start and end address of every range in m_ranges by DELTA. */
+
+ void relocate_addresses (CORE_ADDR delta);
+
private:
/* If the namespace_info is NULL, allocate it via OBSTACK and
@@ -344,6 +357,18 @@ struct block : public allocate_on_obstack<block>
startaddr and endaddr above. */
struct blockranges *m_ranges = nullptr;
+
+ /* The entry address for this block. The value 0 is special and
+ indicates that the entry address has not been set.
+
+ Using 0 as a special value is not ideal, targets for which 0 is a
+ valid code address might run into problems if they want to use 0 as a
+ block's entry address, but the alternative is to carry a flag
+ indicating if m_entry_pc is valid or not, but that would make 'struct
+ block' even bigger, and we want to keep 'struct block' as small as
+ possible (we might have a lot of blocks). */
+
+ CORE_ADDR m_entry_pc = 0;
};
/* The global block is singled out so that we can provide a back-link
@@ -11305,8 +11305,109 @@ get_scope_pc_bounds (struct die_info *die,
*highpc = best_high;
}
+/* Return the base address for DIE (which is represented by BLOCK) within
+ CU. The base address is the DW_AT_low_pc, or if that is not present,
+ the first address in the first range defined by DW_AT_ranges.
+
+ The DWARF standard actually says that if DIE has neither DW_AT_low_pc or
+ DW_AT_ranges then we should search in the parent of DIE for those
+ properties, and so on up the hierarchy, until we find a die with one of
+ those attributes, and use that as the base address. We don't implement
+ that yet simply because we've never encountered a need for it. */
+
+static std::optional<CORE_ADDR>
+dwarf2_die_base_address (struct die_info *die, struct block *block,
+ struct dwarf2_cu *cu)
+{
+ dwarf2_per_objfile *per_objfile = cu->per_objfile;
+
+ struct attribute *attr = dwarf2_attr (die, DW_AT_low_pc, cu);
+ if (attr != nullptr)
+ return per_objfile->relocate (attr->as_address ());
+ else if (block->ranges ().size () > 0)
+ return block->ranges ()[0].start ();
+
+ return {};
+}
+
+/* Set the entry PC for BLOCK which represents DIE from CU. Relies on the
+ range information (if present) already having been read from DIE and
+ stored into BLOCK. */
+
+static void
+dwarf2_record_block_entry_pc (struct die_info *die, struct block *block,
+ struct dwarf2_cu *cu)
+{
+ dwarf2_per_objfile *per_objfile = cu->per_objfile;
+
+ /* Filled with the entry-pc if we can find it. */
+ std::optional<CORE_ADDR> entry;
+
+ /* Set the block's entry PC where possible. */
+ struct attribute *attr = dwarf2_attr (die, DW_AT_entry_pc, cu);
+ if (attr != nullptr)
+ {
+ /* DWARF-5 allows for the DW_AT_entry_pc to be an unsigned constant
+ offset from the containing DIE's base address. We don't limit the
+ constant handling to DWARF-5 though. If a broken compiler emits
+ this for DWARF-4 then we handle it just as we would for DWARF-5. */
+ if (attr->form_is_constant ())
+ {
+ if (attr->form_is_unsigned ())
+ {
+ CORE_ADDR offset = attr->as_unsigned ();
+
+ std::optional<CORE_ADDR> base
+ = dwarf2_die_base_address (die, block, cu);
+
+ if (base.has_value ())
+ entry.emplace (base.value () + offset);
+ }
+ else
+ {
+ /* We could possibly handle signed constants, but this is out
+ of spec, so for now, just complain and ignore it. */
+ complaint (_("Unhandled constant for DW_AT_entry_pc, value (%s)"),
+ plongest (attr->as_nonnegative ()));
+ }
+ }
+ else
+ entry.emplace (per_objfile->relocate (attr->as_address ()));
+ }
+ else
+ entry = dwarf2_die_base_address (die, block, cu);
+
+ if (entry.has_value ())
+ {
+ CORE_ADDR entry_pc = entry.value ();
+
+ /* We sometimes see GCC give an entry-pc that is just before the
+ start of (one of) a block's ranges. In the cases I've seen
+ we'd actually be better off moving the block's range start
+ address to include the entry-pc, but that requires some
+ addtional infrastructure changes, so for now we just adjust
+ the entry-pc to be the block's start address.
+
+ Though this bug is known to occur with GCC, we don't include a
+ producer check, if this does happen with any producer then it's
+ going to cause problems, so lets work around it.
+
+ Then we additionally check for ENTRY_PC being after the block's
+ end address. This has never been observed in the wild, but seems
+ like a cheap sanity check. If the entry_pc falls outside a
+ blocks range then this is going to cause GDB problems, so lets
+ avoid that. Using the block's start as the fallback in this case
+ just replicates GDB's default entry_pc calculation logic if the
+ entry-pc is not specified. */
+ if (entry_pc < block->start () || entry_pc > block->end ())
+ entry_pc = block->start ();
+
+ block->set_entry_pc (entry_pc);
+ }
+}
+
/* Record the address ranges for BLOCK, offset by BASEADDR, as given
- in DIE. */
+ in DIE. Also set the entry PC for BLOCK. */
static void
dwarf2_record_block_ranges (struct die_info *die, struct block *block,
@@ -11361,6 +11462,8 @@ dwarf2_record_block_ranges (struct die_info *die, struct block *block,
block->set_ranges (make_blockranges (objfile, blockvec));
}
+
+ dwarf2_record_block_entry_pc (die, block, cu);
}
/* Check whether the producer field indicates either of GCC < 4.6, or the
@@ -619,14 +619,7 @@ objfile_relocate1 (struct objfile *objfile,
for (block *b : bv->blocks ())
{
- b->set_start (b->start () + delta[block_line_section]);
- b->set_end (b->end () + delta[block_line_section]);
-
- for (blockrange &r : b->ranges ())
- {
- r.set_start (r.start () + delta[block_line_section]);
- r.set_end (r.end () + delta[block_line_section]);
- }
+ b->relocate_addresses (delta[block_line_section]);
/* We only want to iterate over the local symbols, not any
symbols in included symtabs. */
new file mode 100644
@@ -0,0 +1,51 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+volatile int global_var = 0;
+
+void
+foo (void) /* foo decl line */
+{
+ /* This label is used to find the start of 'foo' when generating the
+ debug information. */
+ asm ("foo_label: .globl foo_label");
+
+ /* These labels define a range within foo. */
+ asm ("foo_r1_s: .globl foo_r1_s");
+ ++global_var;
+ asm ("foo_r1_e: .globl foo_r1_e");
+
+ ++global_var;
+
+ asm ("foo_r2_s: .globl foo_r2_s");
+ ++global_var;
+ asm ("foo_middle: .globl foo_middle");
+ ++global_var;
+ asm ("foo_r2_e: .globl foo_r2_e");
+
+ ++global_var;
+
+ asm ("foo_r3_s: .globl foo_r3_s");
+ ++global_var;
+ asm ("foo_r3_e: .globl foo_r3_e");
+}
+
+int
+main (void)
+{
+ asm ("main_label: .globl main_label");
+}
new file mode 100644
@@ -0,0 +1,487 @@
+# Copyright 2024 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test different ways in which DW_AT_entry_pc can be expressed in the
+# DWARF. Also test with DWARF-4 and DWARF-5. See the individule test
+# procs below precise details of what DW_AT_entry_pc forms are tested.
+
+load_lib dwarf.exp
+
+require dwarf2_support
+
+standard_testfile
+
+# This compiles the source file and starts and stops GDB, so run it
+# before calling prepare_for_testing otherwise GDB will have exited.
+get_func_info foo
+
+if { [prepare_for_testing "failed to prepare" ${testfile} \
+ [list ${srcfile}]] } {
+ return -1
+}
+
+if ![runto_main] {
+ return -1
+}
+
+# Address for the middle of foo. This is used as our entry point when
+# the entry_pc is defined as an address.
+set foo_middle_addr [get_hexadecimal_valueof "&foo_middle" "UNKNOWN" \
+ "get address for middle of foo"]
+
+# The FOO_START and FOO_END we get from get_func_info is an expression
+# involving symbols and offsets. To check the 'maint info blocks'
+# output we need these converted into actual addresses.
+set foo_start_addr [get_hexadecimal_valueof "$foo_start" "UNKNOWN" \
+ "get address for start of foo"]
+set foo_end_addr [get_hexadecimal_valueof "$foo_end" "UNKNOWN" \
+ "get address for end of foo"]
+
+# The ranges within foo. Used when foo is defined using ranges rather
+# than a low pc and high pc pair. The entry point is in the middle of
+# the second range.
+foreach var { r1_s r1_e r2_s r2_e r3_s r3_e } {
+ set $var [get_hexadecimal_valueof "&foo_$var" "UNKNOWN" \
+ "get address for foo_$var"]
+}
+
+if [is_ilp32_target] {
+ set ptr_type "data4"
+} else {
+ set ptr_type "data8"
+}
+
+# Generate a suffix number. Called from each of the test procs below
+# to acquire a unique suffix for naming asm files and executables.
+
+set global_test_suffix 0
+proc get_next_suffix {} {
+ global global_test_suffix
+ incr global_test_suffix
+
+ return $global_test_suffix
+}
+
+# Helper for the two build_and_test_* procs below. Combine ASM_FILE
+# with the global SRCFILE and build an executable. Use SUFFIX to give
+# the executable a unique name.
+
+proc build_and_runto_main { suffix asm_file } {
+ if {[prepare_for_testing "failed to prepare" "${::testfile}-${suffix}" \
+ [list $::srcfile $asm_file] {nodebug}]} {
+ return false
+ }
+
+ if ![runto_main] {
+ return false
+ }
+
+ return true
+}
+
+
+# Combine ASM_FILE with the global SRCFILE and build an executable,
+# use SUFFIX to make the executable name unique.
+#
+# Then check the blocks at the symbol `foo_middle'. The inner most
+# block should be a block for 'foo' with a continuous address range
+# and an entry address of ENTRY_PC.
+
+proc build_and_test_continuous { suffix asm_file entry_pc } {
+ if { ![build_and_runto_main $suffix $asm_file] } {
+ return false
+ }
+
+ gdb_test "maint info blocks foo_middle" \
+ [multi_line \
+ "\\\[\[^\]\]+\\\] $::foo_start_addr\.\.$::foo_end_addr" \
+ " entry pc: $entry_pc" \
+ " function: foo" \
+ " is contiguous"]
+}
+
+# Combine ASM_FILE with the global SRCFILE and build an executable,
+# use SUFFIX to make the executable name unique.
+#
+# Then check the blocks at the symbol `foo_middle'. The inner most
+# block should be a block for 'foo' which has 3 address ranges and an
+# entry address of ENTRY_PC.
+
+proc build_and_test_ranged { suffix asm_file entry_pc } {
+ if { ![build_and_runto_main $suffix $asm_file] } {
+ return false
+ }
+
+ gdb_test "maint info blocks foo_middle" \
+ [multi_line \
+ "\\\[\[^\]\]+\\\] $::r1_s\.\.$::r3_e" \
+ " entry pc: $entry_pc" \
+ " function: foo" \
+ " address ranges:" \
+ " $::r1_s\.\.$::r1_e" \
+ " $::r2_s\.\.$::r2_e" \
+ " $::r3_s\.\.$::r3_e" ]
+}
+
+# The function's address range is defined using low/high bounds and
+# the entry_pc attribute is not given. The function's entry PC will
+# default to the low address.
+
+proc_with_prefix use_low_high_bounds_without_entry_pc { dwarf_vesion } {
+ set suffix [get_next_suffix]
+
+ # Make some DWARF for the test.
+ set asm_file [standard_output_file "$::testfile-dw-$suffix.S"]
+ Dwarf::assemble $asm_file {
+ global srcfile
+
+ declare_labels lines_table
+
+ set foo_decl_line [gdb_get_line_number "foo decl line"]
+
+ cu { version $::dwarf_version } {
+ compile_unit {
+ {producer "gcc"}
+ {language @DW_LANG_C}
+ {name ${srcfile}}
+ {comp_dir /tmp}
+ {stmt_list $lines_table DW_FORM_sec_offset}
+ } {
+ subprogram {
+ {name foo}
+ {decl_file 1 data1}
+ {decl_line $foo_decl_line data1}
+ {decl_column 1 data1}
+ {low_pc $::foo_start addr}
+ {high_pc $::foo_len $::ptr_type}
+ {external 1 flag}
+ }
+ }
+ }
+
+ lines {version 2} lines_table {
+ include_dir "$::srcdir/$::subdir"
+ file_name "$srcfile" 1
+ }
+ }
+
+ build_and_test_continuous $suffix $asm_file $::foo_start_addr
+}
+
+# The function's address range is defined using low/high bounds and an
+# entry_pc attribute is given (which contains an address), which will
+# be used as the function's entry address.
+
+proc_with_prefix use_low_high_bounds_with_entry_pc { dwarf_version } {
+ set suffix [get_next_suffix]
+
+ # Make some DWARF for the test.
+ set asm_file [standard_output_file "$::testfile-dw-$suffix.S"]
+ Dwarf::assemble $asm_file {
+ global srcfile
+
+ declare_labels lines_table
+
+ set foo_decl_line [gdb_get_line_number "foo decl line"]
+
+ cu { version $::dwarf_version } {
+ compile_unit {
+ {producer "gcc"}
+ {language @DW_LANG_C}
+ {name ${srcfile}}
+ {comp_dir /tmp}
+ {stmt_list $lines_table DW_FORM_sec_offset}
+ } {
+ subprogram {
+ {name foo}
+ {decl_file 1 data1}
+ {decl_line $foo_decl_line data1}
+ {decl_column 1 data1}
+ {low_pc $::foo_start addr}
+ {high_pc $::foo_len $::ptr_type}
+ {external 1 flag}
+ {entry_pc foo_middle addr}
+ }
+ }
+ }
+
+ lines {version 2} lines_table {
+ include_dir "$::srcdir/$::subdir"
+ file_name "$srcfile" 1
+ }
+ }
+
+ build_and_test_continuous $suffix $asm_file $::foo_middle_addr
+}
+
+# The function's address range is defined using low/high bounds and an
+# entry_pc attribute is given (which contains an offset from the base
+# address), which will be used to compute the function's entry address.
+
+proc_with_prefix use_low_high_bounds_with_entry_offset { dwarf_version } {
+ set suffix [get_next_suffix]
+
+ # Make some DWARF for the test.
+ set asm_file [standard_output_file "$::testfile-dw-$suffix.S"]
+ Dwarf::assemble $asm_file {
+ global srcfile
+
+ declare_labels lines_table
+
+ set foo_decl_line [gdb_get_line_number "foo decl line"]
+
+ set foo_offset [expr $::foo_middle_addr - $::foo_start_addr]
+
+ cu { version $::dwarf_version } {
+ compile_unit {
+ {producer "gcc"}
+ {language @DW_LANG_C}
+ {name ${srcfile}}
+ {comp_dir /tmp}
+ {stmt_list $lines_table DW_FORM_sec_offset}
+ } {
+ subprogram {
+ {name foo}
+ {decl_file 1 data1}
+ {decl_line $foo_decl_line data1}
+ {decl_column 1 data1}
+ {low_pc $::foo_start addr}
+ {high_pc $::foo_len $::ptr_type}
+ {external 1 flag}
+ {entry_pc $foo_offset data4}
+ }
+ }
+ }
+
+ lines {version 2} lines_table {
+ include_dir "$::srcdir/$::subdir"
+ file_name "$srcfile" 1
+ }
+ }
+
+ build_and_test_continuous $suffix $asm_file $::foo_middle_addr
+}
+
+# The function's address range is defined using range information. No
+# entry_pc attribute is used. The entry PC for the function will
+# default to the first address of the first range.
+
+proc_with_prefix use_ranges_without_entry_pc { dwarf_version } {
+ set suffix [get_next_suffix]
+
+ # Make some DWARF for the test.
+ set asm_file [standard_output_file "$::testfile-dw-$suffix.S"]
+ Dwarf::assemble $asm_file {
+ upvar dwarf_version dwarf_version
+ global srcfile
+
+ declare_labels lines_table ranges_label
+
+ set foo_decl_line [gdb_get_line_number "foo decl line"]
+
+ cu { version $::dwarf_version } {
+ compile_unit {
+ {producer "gcc"}
+ {language @DW_LANG_C}
+ {name ${srcfile}}
+ {comp_dir /tmp}
+ {stmt_list $lines_table DW_FORM_sec_offset}
+ {low_pc 0 addr}
+ } {
+ subprogram {
+ {name foo}
+ {decl_file 1 data1}
+ {decl_line $foo_decl_line data1}
+ {decl_column 1 data1}
+ {external 1 flag}
+ {ranges ${ranges_label} DW_FORM_sec_offset}
+ }
+ }
+ }
+
+ lines {version 2} lines_table {
+ include_dir "$::srcdir/$::subdir"
+ file_name "$srcfile" 1
+ }
+
+ if { $dwarf_version == 5 } {
+ rnglists {} {
+ table {} {
+ ranges_label: list_ {
+ start_end foo_r1_s foo_r1_e
+ start_end foo_r2_s foo_r2_e
+ start_end foo_r3_s foo_r3_e
+ }
+ }
+ }
+ } else {
+ ranges { } {
+ ranges_label: sequence {
+ range foo_r1_s foo_r1_e
+ range foo_r2_s foo_r2_e
+ range foo_r3_s foo_r3_e
+ }
+ }
+ }
+ }
+
+ build_and_test_ranged $suffix $asm_file $::r1_s
+}
+
+# The function's address range is defined using range information and
+# an entry_pc attribute (which is an address) is used, this will be
+# the entry PC for the function.
+
+proc_with_prefix use_ranges_with_entry_pc { dwarf_version } {
+ set suffix [get_next_suffix]
+
+ # Make some DWARF for the test.
+ set asm_file [standard_output_file "$::testfile-dw-$suffix.S"]
+ Dwarf::assemble $asm_file {
+ upvar dwarf_version dwarf_version
+ global srcfile
+
+ declare_labels lines_table ranges_label
+
+ set foo_decl_line [gdb_get_line_number "foo decl line"]
+
+ cu { version $::dwarf_version } {
+ compile_unit {
+ {producer "gcc"}
+ {language @DW_LANG_C}
+ {name ${srcfile}}
+ {comp_dir /tmp}
+ {stmt_list $lines_table DW_FORM_sec_offset}
+ {low_pc 0 addr}
+ } {
+ subprogram {
+ {name foo}
+ {decl_file 1 data1}
+ {decl_line $foo_decl_line data1}
+ {decl_column 1 data1}
+ {external 1 flag}
+ {ranges ${ranges_label} DW_FORM_sec_offset}
+ {entry_pc foo_middle addr}
+ }
+ }
+ }
+
+ lines {version 2} lines_table {
+ include_dir "$::srcdir/$::subdir"
+ file_name "$srcfile" 1
+ }
+
+ if { $dwarf_version == 5 } {
+ rnglists {} {
+ table {} {
+ ranges_label: list_ {
+ start_end foo_r1_s foo_r1_e
+ start_end foo_r2_s foo_r2_e
+ start_end foo_r3_s foo_r3_e
+ }
+ }
+ }
+ } else {
+ ranges { } {
+ ranges_label: sequence {
+ range foo_r1_s foo_r1_e
+ range foo_r2_s foo_r2_e
+ range foo_r3_s foo_r3_e
+ }
+ }
+ }
+ }
+
+ build_and_test_ranged $suffix $asm_file $::foo_middle_addr
+}
+
+# The function's address range is defined using range information and
+# an entry_pc attribute (which is an offset) is used, this will be
+# used to calculate the entry PC for the function.
+
+proc_with_prefix use_ranges_with_entry_offset { dwarf_version } {
+ set suffix [get_next_suffix]
+
+ # Make some DWARF for the test.
+ set asm_file [standard_output_file "$::testfile-dw-$suffix.S"]
+ Dwarf::assemble $asm_file {
+ upvar dwarf_version dwarf_version
+ global srcfile
+
+ declare_labels lines_table ranges_label
+
+ set foo_decl_line [gdb_get_line_number "foo decl line"]
+
+ set foo_offset [expr $::foo_middle_addr - $::r1_s]
+
+ cu { version $::dwarf_version } {
+ compile_unit {
+ {producer "gcc"}
+ {language @DW_LANG_C}
+ {name ${srcfile}}
+ {comp_dir /tmp}
+ {stmt_list $lines_table DW_FORM_sec_offset}
+ {low_pc 0 addr}
+ } {
+ subprogram {
+ {name foo}
+ {decl_file 1 data1}
+ {decl_line $foo_decl_line data1}
+ {decl_column 1 data1}
+ {external 1 flag}
+ {ranges ${ranges_label} DW_FORM_sec_offset}
+ {entry_pc $foo_offset data4}
+ }
+ }
+ }
+
+ lines {version 2} lines_table {
+ include_dir "$::srcdir/$::subdir"
+ file_name "$srcfile" 1
+ }
+
+ if { $dwarf_version == 5 } {
+ rnglists {} {
+ table {} {
+ ranges_label: list_ {
+ start_end foo_r1_s foo_r1_e
+ start_end foo_r2_s foo_r2_e
+ start_end foo_r3_s foo_r3_e
+ }
+ }
+ }
+ } else {
+ ranges { } {
+ ranges_label: sequence {
+ range foo_r1_s foo_r1_e
+ range foo_r2_s foo_r2_e
+ range foo_r3_s foo_r3_e
+ }
+ }
+ }
+ }
+
+ build_and_test_ranged $suffix $asm_file $::foo_middle_addr
+}
+
+# Run the tests.
+foreach_with_prefix dwarf_version { 4 5 } {
+ use_low_high_bounds_without_entry_pc $dwarf_version
+ use_low_high_bounds_with_entry_offset $dwarf_version
+ use_low_high_bounds_with_entry_pc $dwarf_version
+ use_ranges_without_entry_pc $dwarf_version
+ use_ranges_with_entry_pc $dwarf_version
+ use_ranges_with_entry_offset $dwarf_version
+}
new file mode 100644
@@ -0,0 +1,41 @@
+/* Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include "attributes.h"
+
+volatile int global = 0;
+
+__attribute__((noinline)) ATTRIBUTE_NOCLONE void
+foo (int arg)
+{
+ global += arg;
+}
+
+inline __attribute__((always_inline)) int
+bar (int val)
+{
+ if (global == val)
+ return 1;
+ foo (1);
+ return 1;
+}
+
+int
+main (void)
+{
+ if ((global && bar (1)) || bar (2))
+ return 0;
+ return 1;
+}
new file mode 100644
@@ -0,0 +1,51 @@
+# Copyright 2024 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test some code which relies on GDB interpreting the DW_AT_entry_pc
+# correctly in order to place the breakpoints. This was tested with
+# versions of GCC between 8.4 and 14.2 and in all cases the entry_pc
+# was required.
+#
+# Testing with Clang 9.0.1 and 15.0.2 seemed to indicate that the
+# Clang generated code didn't depend on the entry_pc being parsed.
+
+standard_testfile
+
+set options {debug optimize=-O2}
+lappend_include_file options $srcdir/lib/attributes.h
+
+if { [prepare_for_testing "failed to prepare" $binfile $srcfile $options] } {
+ return
+}
+
+if ![runto_main] {
+ return
+}
+
+gdb_breakpoint "bar"
+set bp_bar_num [get_integer_valueof "\$bpnum" "*UNKNOWN*" \
+ "get number of bar breakpoint"]
+
+gdb_breakpoint "foo"
+set bp_foo_num [get_integer_valueof "\$bpnum" "*UNKNOWN*" \
+ "get number of foo breakpoint"]
+
+gdb_test "continue" \
+ "Breakpoint ${bp_bar_num}(?:\\.$decimal)?, bar .*" "continue to bar"
+
+gdb_test "continue" \
+ "Breakpoint ${bp_foo_num}(?:\\.$decimal)?, foo .*" "continue to foo"
+
+gdb_continue_to_end