Bug#1143851: hppa-linux-gnu-gcc does not honor -ffreestanding, generating referencs to memset

On 2026-08-12 3:28 a.m., Michael Tokarev wrote:
> Control: found -1 16.2.0-1
> 
> On 8/7/26 17:48, John David Anglin wrote:
>> Hi Michael,
> 
> Hi!  Thank you for your reply.
> 
>> I suggest you file a gcc bug report.  You would need to provide the .i file and compile
>> options.  Code simplification is helpful.
> 
> Yeah, I'm at it, for a few days already :)
> 
>> memset is typically provided by libc.  One option might be for you to provide a simple
>> implementation of it with your code.
> 
> The prob here is that memset *is* provided by the code already.  When I naively added
> another one, it conflicted with the already-provided by the code.  But the one provided
> is not found by the linker.
> 
> And there are a few more observations here.  First, -ffreestanding should ensure there's
> no calls to memset generated.  Second, there are no calls to memset found in the generated
> disassembly of the functions in question (where the linker complains about missing
> memset) - though I don't know hppa assembly.  3rd, in objdump -t output, I do see *two*
> variants of memset symbol - more on this below.  And 4th, this seems to be happening
> only when using -fwhole-program option - which makes the code simplification for the
> gcc bug report quite a bit more difficult.
> 
> Now, two variants of memset.  Here they are:
> 
> 00003eec l     F .text    00000020 memset.constprop.0
> 00000000         *UND*    00000000 memset
> 
> The first is the actual memset provided by the code in question.
> And the second is the undefined reference.

If you add -save-temps to the compile options for your program, the .i, .s and .o files
will be generated.  I suspect you will only see memset.constprop.0 in the .s and .o
intermediate files.  However, there are likely some undefined symbols in the .o that
need to be resolved by linking against libgcc.  There are millicode routines in it for
multiplication, etc, and routines for unwind EH support (e.g., uw_frame_state_for) that
use memset.
> It feels like the prob is .constprop.0 suffix, added with -fwhole-program?  Because
> all other symbols defined by the code have the same .constprop.0 suffix.
> 
> If my teory is right, we have TWO bugs here.  First is -fwhole-program renaming
> all symbols, so that internal references to them can't be resolved.  And second
> is -ffreestanding which actually does not generate free-standing code.
> 
>> I don't believe this issue is hppa specific.  The -ffreestanding option is handled
>> by common code and the pa backend does not do anything with this option.
>> 00000000         *UND*    00000000 memset
> 
>> The pa backend also does not issue calls to memset.  It doesn't deal with the initialization
>> or layout of structs.  But hppa is big endian.  This and some other factors affect struct
>> initialization and layout.
> 
> Well, whatever it is, so far I only see it on hppa (and hhpa64) - or actually with
> hppa[64]-linux-gnu-gcc.  I'm building qemu, and it uses a lot of other compilers.
> 
> However, only hppa and x86 builds with -fwhole-program.
> 
> Without -fwhole-program it seems to work.  But I dunno if the resulting binary
> works.

At the moment, I would say hppa is not compatible with -fwhole-program.  The
simplest fix might be to add "_attribute__((used, externally_visible))" to the memcpy
declaration in your code.

This what google said about this:

That context completely changes the problem. In the HPPA (PA-RISC) architecture, this is a classic bootstrap/runtime boundary issue.When a user
provides their own runtime override for a standard library function like memset, and the compiler optimization engine applies -fwhole-program,
it localizes and renames the user's memset (e.g., to memset.isra.0).However, HPPA's heavy reliance on out-of-line millicode routines (like
$$divI, $$mulI) and compiler-generated calls to standard builtins like memset (which the middle-end emits implicitly for structural
initializations during exception handling and unwind setups in libgcc) creates an immediate breakage. The generated code still expects a
hardcoded symbol literal memset, but the actual code has been completely hidden or transformed by the compiler.To prevent GCC from renaming or
localizing a built-in symbol block at the target level, you need to use specific backend configuration hooks.1. The Right Hook:
TARGET_ASM_OUTPUT_ANCHOR / TARGET_C_MODE_FOR_FLOATING_TYPE (The Symbol Table Level)Because -fwhole-program intercepts declarations at the symbol
table (symtab) stage during Interprocedural Analysis (IPA), modifying the assembly generation phase is too late.To override this layout
programmatically within gcc/config/pa/pa.cc, you must enforce visibility during compilation. The idiomatic way to handle this in a GCC target
backend is to explicitly register target-specific builtins using the TARGET_COMMON_TARGET_ATTRIBUTE_TABLE or by patching the backend
initialization function where target attributes are registered.You can modify pa.cc (or pa-pinsn.cc depending on layout) to explicitly find
these declarations during compilation and assign them the properties of externally_visible.c/* In gcc/config/pa/pa.cc */
void
pa_preserve_runtime_builtins (tree decl)
{
  if (DECL_NAME (decl) && IDENTIFIER_POINTER (DECL_NAME (decl)))
    {
      const char *name = IDENTIFIER_POINTER (DECL_NAME (decl));
      /* Protect memset, millicode names, and other vital symbols */
      if (strcmp (name, "memset") == 0 || strncmp (name, "$$", 2) == 0)
        {
          DECL_PRESERVED_P (decl) = 1;
          if (lookup_attribute ("externally_visible", DECL_ATTRIBUTES (decl)) == NULL_TREE)
            {
              DECL_ATTRIBUTES (decl) = tree_cons (
                get_identifier ("externally_visible"),
                NULL_TREE,
                DECL_ATTRIBUTES (decl)
              );
            }
        }
    }
}
Use code with caution.2. Utilizing SET_DECL_ASSEMBLER_NAMEIf the middle-end attempts to clone or mangle memset into an internal static reference
during clone generation passes, the HPPA backend can trap the symbol layout using the macro SET_DECL_ASSEMBLER_NAME.By overriding how the
assembler name is assigned to standard runtime blocks, you can ensure that the string literal targeted by the backend's millicode emitting logic
(like output_millicode_call) matches what the compiler maps.3. The Cleanest Intermediate Fix for the debian/patches ArrayIf modifying the
middle-end compiler logic introduces structural regression to standard IPA optimization passes, you can enforce protection via the target_clones
or architectural default definitions.By modifying the header target layout files for HPPA (gcc/config/pa/pa.h), you can force the compilation
environment to append specific compiler properties to standard libgcc symbols via UNSET_FRONTEND_OPTIMIZATION:c/* Force compiler builtins to
retain globally exposed symbols for millicode compatibility */
#define SUBTARGET_ATTRIBUTE_TABLE \
  { "interrupt", 0, 0, false, true, true, false, NULL, NULL },
Use code with caution.Direct Verification PointBecause this issue impacts code compiled with -fwhole-program when stepping through the landing
pads for DWARF2 unwind routines (which heavily rely on clean block allocation via memset in libgcc/unwind-dw2.c), you can confirm your hook fix
is working by compiling a simple test case using -fwhole-program and checking the output of:bashhppa-linux-gnu-gcc -fwhole-program -O2 test.c -S
-o - | grep -E "(memset|\$\$)"
Use code with caution.If the output maps direct calls to un-mangled memset strings instead of memset.isra.X, the backend mutation pass has
successfully preserved the ABI boundaries.Are you building this compiler directly as a native cross-toolchain pass for the Debian unstable (sid)
ports architecture, or are you building an upstream tracking branch?

Dave