bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/28867] Mingw to generate bogus.o on French locale


From: nickc at redhat dot com
Subject: [Bug binutils/28867] Mingw to generate bogus.o on French locale
Date: Mon, 21 Mar 2022 11:50:52 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=28867

--- Comment #9 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Eric Pouech from comment #8)
Hi Eric,


> -    <203>   DW_AT_decl_column : 49
> +    <203>   DW_AT_decl_column : 15

> just to say I don't grasp where this modification in dwarf's column comes
> from
> (AFAICT fail.s has column information which is consistent with fail.o)
> 
> I have no evidence that this variation in the .o files has any relationship
> with the failure (or hasn't)... but since we can't grasp anything serious,
> it may be worth checking ;-)

Sorry - I think that that is a red herring.

> maybe, it does ring some bell to you?

Not really.  I think that we are looking at three possibilities here:

  * A bug in the compiler used to build the assembler that you 
    are using, so that it mis-behaves in a subtle manner.  Since
    I am probably using a different compiler to build my sources,
    this might explain why I cannot reproduce the bug.

  * A hardware failure on your test machine (a bad memory chip maybe ?)
    Pretty unlikely I know, but it would explain why only you seem to
    have these problems.  If true though, I would expect you to be
    encountering problems with other, unrelated programs.

  * An uninitialised memory bug in the assembler sources, such that a 
    random value is being used somewhere.  Different host environments
    tend to initialise memory differently, so this might explain why
    it works for me (eg because on my host, allocated memory is always
    initialised to zero, even if not specifically requested).


I am not sure what to suggest now.  You could try running the assembler
under a tool like valgrind and see if that shows up anything.  Or compile
the assembler with address sanitization and/or undefined behaviour 
sanitization enabled and then see if something is detected.   There are 
also memory testers that you can run to see if your memory banks are
behaving correctly.  Might be worth a shot, even if it is just for peace
of mind.

Sorry - I am not sure what else I can do.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]